User stories and decomposing requirements
Download as PPTX, PDF2 likes1,285 views
This document discusses user stories, which describe features from the perspective of users to help focus product development. User stories have a simple format, typically including the user's role, goal and requested functionality. They promote transparency, focus on users and valuable outcomes. Large or complex stories can be broken down into smaller stories by considering workflows, acceptance criteria and other techniques.
User stories and decomposing requirements
- 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
Editor's Notes
- #9: 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.