User stories and decomposing requirements

684 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
684
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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.
  • User stories and decomposing requirements

    1. 1. USER STORIES & DECOMPOSING REQUIREMENTS
    2. 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. 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. 4. USER STORY FORMATS FOCUS ON THE BUSINESS GOAL •TITLE •IN ORDER TO <BUSINESS GOAL> •AS <A ROLE> •I WANT <FUNCTIONALITY>
    5. 5. USER STORY FORMATS FOCUS ON THE ROLE •TITLE •AS <A ROLE> •IN ORDER TO <BUSINESS GOAL> •I WANT <FUNCTIONALITY>
    6. 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. 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. 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. 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. 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. 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
    12. 12. WWW.CODESPRINTERS.COM THANK YOU v5

    ×