2. WHAT IS A USER STORY?
• A REGULAR STORY IS ABOUT SOME PERSONS, THEY ARE IN A
SITUATION, SOMETHING HAPPENS THAT IS INTERESTING, THEN THERE
IS AN OUTCOME AND AN END
• SOMETIMES THERE IS A MORAL OR SOME RATIONALE FOR IT ALL
• USER STORIES ARE STORIES ABOUT A USER OF OUR PRODUCT.
THERE IS A SITUATION, THE USER DOES SOMETHING AND THE
PRODUCT RESPONDS GIVING THE USER SOME RESULT (HOPEFULLY
OF VALUE FOR THE USER)
3. WHAT IS A USER STORY?
• A USER’S NEED
• A PLANNING ITEM
• A REQUIREMENT
• A (CHUNK OF) PRODUCT DESCRIPTION
• A COMMUNICATION TOOL
• A DISCUSSION OPENER
4. USER STORY FORMATS
FOCUS ON THE BUSINESS GOAL
•TITLE
•IN ORDER TO <BUSINESS GOAL>
•AS <A ROLE>
•I WANT <FUNCTIONALITY>
5. USER STORY FORMATS
FOCUS ON THE ROLE
•TITLE
•AS <A ROLE>
•IN ORDER TO <BUSINESS GOAL>
•I WANT <FUNCTIONALITY>
6. WHY USER STORIES?
• USER STORIES PROMOTE TRANSPARENCY BEING INTUITIVELY
UNDERSTANDABLE FOR ALL INVOLVED (USUALLY ALSO FOR
STAKEHOLDERS)
• HELP FOCUS ON THE USER AND VALUABLE BUSINESS OUTCOMES
• HELP START DISCUSSIONS – BUT ALSO HELP CAPTURE THEIR
OUTCOMES
7. GWT – GIVEN WHEN
THEN
• “GIVEN-WHEN-THEN” – PART OF THE BDD APPROACH, GAINING
POPULARITY AS ACCEPTANCE TESTING SO FORMULATED
REQUIREMENTS CAN BE AUTOMATED (JBEHAVE, RSPEC, CUCUMBER
ETC.).
• ALSO USEFUL WITHOUT BDD&TOOLS FOR DESCRIBING
REQUIREMENTS FOR SYSTEMS WITHOUT HUMAN USERS WHICH
USUALLY ARE STATE MACHINES RESPONDING TO EXTERNAL EVENTS
8. GIVEN WHEN THEN
DETAILS
• STRUCTURE:
• GIVEN <INITIAL CONTEXT>
• WHEN <ACTION / EVENT>
• THEN <OUTCOME>
• EXAMPLE:
• GIVEN I AM A PREMIUM USER AND I HAVE A HOTEL RESERVATION
• WHEN I CANCEL IT UP TO 4 DAYS BEFORE TRAVELING
• THEN I GET FULL REFUND
9. TYPES OF LARGE
STORIES
• COMPOUND STORIES - USUALLY MADE UP OF SEVERAL SMALLER
STORIES
• COMPLEX STORIES - USUALLY INHERENTLY LARGE STORIES,
OFTEN BECAUSE THERE IS SOME UNCERTAINTY ABOUT WHAT NEEDS
TO BE DONE.
10. BREAKING DOWN USER
STORIES
• CRUD – CREATE, READ, UPDATE, DELETE
• ACCEPTANCE CRITERIA – SEPARATELY POSITIVE SCENARIO, NEGATIVE
SCENARIO, EXCEPTIONS ETC.
• DECISION TREES – CONSIDER, THEN IMPLEMENT BRANCHES
• WORKFLOW STEPS – WORKFLOW SEQUENCE ONE BY ONE
• NONE, ONE, MANY – CONSIDER SEPARATELY SIZES
• EXTERNAL (INCREMENTAL) QUALITY – GRADUALLY IMPROVE UI,
PERFORMANCE ETC.
• “SPIKES” – TIME-BOXED EXPLORATION
11. SOURCES
• “GROWING AGILE” – BLOG POST ABOUT BREAKING DOWN
REQUIREMENTS
• HTTP://GROWINGAGILE.CO.ZA/2012/12/BREAKING-DOWN-USER-
STORIES/
• “PATTERNS FOR SPLITTING USER STORIES” – RICHARD LAWRENCE
• HTTP://WWW.RICHARDLAWRENCE.INFO/2009/10/28/PATTERNS-
FOR-SPLITTING-USER-STORIES/
• “USER STORIES APPLIED” – MIKE COHN, 2004 ISBN 978-0321205681
The last sentence is just an opinion/suggestion. I think when dealing with systems like eg. routers, transaction systems or some SCADA systems where there are no human users specifying reqs as user stories feels awkward and doesn’t help in testing. GWT is a better idea there, though it can of course be used with all kinds of systems.