際際滷

際際滷Share a Scribd company logo

User stories and decomposing requirements

Download as PPTX, PDF
Andy Brandt
Andy Brandt

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.

1 of 12
Downloaded 21 times
USER STORIES & DECOMPOSING REQUIREMENTS
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)
WHAT IS A USER STORY? A USERS NEED A PLANNING ITEM A REQUIREMENT A (CHUNK OF) PRODUCT DESCRIPTION A COMMUNICATION TOOL A DISCUSSION OPENER
USER STORY FORMATS FOCUS ON THE BUSINESS GOAL TITLE IN ORDER TO <BUSINESS GOAL> AS <A ROLE> I WANT <FUNCTIONALITY>
USER STORY FORMATS FOCUS ON THE ROLE TITLE AS <A ROLE> IN ORDER TO <BUSINESS GOAL> I WANT <FUNCTIONALITY>
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
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
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
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.
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
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
WWW.CODESPRINTERS.COM THANK YOU v5

More Related Content

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 USERS 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 doesnt help in testing. GWT is a better idea there, though it can of course be used with all kinds of systems.