How do you get more out of your User Stories?
36 likes26,950 views
The document provides guidance on how to effectively write and use user stories in Agile software development. It discusses key principles such as writing user stories from the perspective of the end user to ensure they provide business value. The document also covers best practices for user stories, such as making them independent, negotiable, estimable, and testable. Tips are provided on properly sizing user stories and determining acceptance criteria to know when a story is complete. Common anti-patterns for user stories are also identified.
![Non-functional
requirements as…
Acceptance Criteria
As a customer, I want to be able to pay by
PayPal, so that I can complete my
purchase.
[Acceptance Criteria]
- payment confirmed within 5 seconds
- handle 100 concurrent payments
- encrypted redirect to PayPal
…
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013](https://image.slidesharecdn.com/gettingmoreoutofuserstories-130405024009-phpapp01-140120040519-phpapp02/85/How-do-you-get-more-out-of-your-User-Stories-28-320.jpg)
![Non-functional
requirements as…
Acceptance Criteria
[CONSTRAINT]
Separate User Stories
As the CTO, I want the system to use our existing
Constraint Cards
orders database rather than create a new one,
so that we don’t have one more database to
maintain.
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
© 2013](https://image.slidesharecdn.com/gettingmoreoutofuserstories-130405024009-phpapp01-140120040519-phpapp02/85/How-do-you-get-more-out-of-your-User-Stories-30-320.jpg)
How do you get more out of your User Stories?
- 1. How do you get more out of your user stories?
- 2. Let’s first refresh our basics © 2013
- 3. Key Agile principles ! Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ! We welcome changing requirements, even late in development. ! Business and IT teams must work together. http://www.agilemanifesto.org/principles.html © 2013
- 4. What is a user story? = Card + Conversation + Confirmation © 2013
- 5. Card What is a user story? #32 As a use r I want t o do som ething so that s ome bene fit is received ! Physical token ! Used in planning ! Reminder for a conversation ! Often annotated © 2013
- 6. Conversation What is a user story? ! Requirement itself ! Verbal conversation / workshops ! Supplemented with documents / wireframes / mocks © 2013
- 7. Confirmation What is a user story? #32 Given < precondi tions> When <t rigger> Then <e xpected outcomes > ! Acceptance criteria ! Used to determine when the story is done © 2013
- 8. Now, let’s see what makes a good user story? © 2013
- 9. What makes a good user story? The INVEST guideline for writing a good story Independent Negotiable Valuable Estimable Small Testable http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ © 2013
- 10. What makes a good user story? Pay by Visa Pay by MasterCard Independent Negotiable Pay by AmEx Pay by Credit Card Valuable Estimable Small þ Do not overlap your stories in concept. þ When sequencing the stories, try to find their natural order. Testable The order of stories should not restrict your customer’s ability to reprioritize or move stories out of scope. © 2013
- 11. What makes a good user story? Independent Negotiable Valuable As a purchaser, I want th e receipt to display the da te of my purchase in ISO 86 01 format Comic Sans 12 pt font with 9pt leading, so that I can maintain my records. hen I to indicate w e receipt tain my aser, I want th at I can main As a purch ase, so th ted the purch comple records. Estimable þ Stories are negotiable...and negotiated. þ Remember, your story is the essence of the requirement and not an explicit Small þ Sign off stories with working software. contract. Testable Avoid signing off written stories before they are played, as it creates contractual documents that shift the focus to documentation. © 2013
- 12. What makes a good user story? Independent Negotiable Valuable Estimable Small Testable As a developer/DBA , I want a new table in the Orders DB to capture shipping informatio n, so that ??? eferred cify my pr e to spe ther t to be abl address o wan m er , I ip to an As a custo at I can sh ls, so th ping detai ship dress y billing ad than m þ Your stories need to be valuable to and understandable by your customer. þ They need to be framed from your customer’s perspective. If it is difficult to write the "so that....” part easilyyou might want to consider the story’s value and purpose. Avoid layer-based development. Instead choose vertical slices of functionality. Technical debt are not user stories. © 2013
- 13. What makes a good user story? Independent Negotiable As a good world citize n, I want world peace , so that we can all live in harmony. aypa o pay by P able t want to be goer, I card. s a movie my credit A to use don’t have that I l, so Valuable þ Your stories should have boundaries so you know when you are “done” and Estimable þ Your stories should be digestible by the team so they can estimate them. þ Keep your stories understandable and of consistent granularity. þ “Spike” stories that your team has difficulty understanding. Small what is required to be “done”. Testable Avoid “catch-all” stories with uncertain estimates. Don’t get bogged with precision and detail. © 2013
- 14. What makes a good user story? Independent Negotiable Valuable Estimable Small As a movie goer, I wa nt to be able to find and purchase movie tick ets online, so that I h ave something to do ton ight. le, ovie by tit nd a m e able to fi a movie I am ant to b tails of e goer, I w s a movi ate the de A ckly loc t I can qui s o t ha in. interested þ Keep your stories small enough to be measured and tracked. þ Keep your story descriptions short and concise. Testable Stories should be measured in days not weeks. © 2013
- 15. What makes a good user story? Improve readability lete term placed with comp All acronyms re Independent Negotiable inology A user must never have to wait long for a screen to appear New screens appear within 2 seconds 95% of time Valuable Estimable Small þ To know when your story is done, it needs to be testable. þ Define acceptance criteria that are clear and precise so you know when you are done and have delivered value. Testable First define your tests and then develop. © 2013
- 16. How do you size your stories? © 2013
- 17. How do you size your stories? Advantages of larger stories Larger Vs. Smaller No ‘challenge’ of splitting Perceived ‘efficiencies’ Clearer business value Easier to prioritize Advantages of smaller stories Accurate estimates Finding t he right sto ry size can be h ard Planning flexibility Measure of progress Understanding of scope © 2013
- 18. How do you size your stories? § § § § Agree on target story size with the development team. The exercise is a joint effort with the customer and the development team. Don’t break down stories too soon - progressively elaborate. Use story complexity, operational (eg. CRUD) and data boundaries as guides. Breaking down stories © 2013
- 19. How do you know when your story is done? © 2013
- 20. How do you know when your story is done? Tips for writing acceptance criteria Given < some in itial con text> when <a n event occurs> then <en s ure som e outcom es> þ Define “complete” with the customer þ Write acceptance criteria collaboratively with the customer þ All the criteria must be met before the story is “complete” þ Consider using a template þ Include all Risks, Assumptions, Issues and Dependencies (RAID) © 2013
- 21. How do you know when your story is done? Smart Be smart with Measurable Possible to observe and quantify acceptance criteria Achievable Capable of existing or taking place Relevant Having a connection Timely When will the outcome be observed? Explicitly defined and definite © 2013
- 22. Lifecycle of a story © 2013
- 23. Lifecycle of a story “ The fundamental idea is that you do just barely enough modelling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details as you need to…just-in-time. * * * -- Scott W. Ambler Why “just-‐in-‐time”? § § § § Reduces potential waste. Provides flexibility to change, prioritize. Enables learning from delivery. Tighter feedback loop between business and the delivery team. © 2013 ”
- 24. Lifecycle of a story #1. Start at the Product Level ! Develop an understanding of the breadth § Objectives/vision statements § Elevator pitch § Product box § User roles & goals § Context diagrams § High-level domain model § Feature lists § Paper prototypes § … Product Families Themes Feature Sets Features / Epics Stories © 2013
- 25. Lifecycle of a story #1. Start at the Product Level #2. Examine the Release Level ! Take a closer look at a subset of features: § Data models § Business needs § Architectural dependencies § Quality attributes (Non-Functional Requirements) § Personas/actors § Define epics § More paper prototyping § … Product Families Themes Feature Sets Features / Epics Stories © 2013
- 26. Lifecycle of a story #1. Start at the Product Level #2. Examine the Release Level #3. Deep-dive into the Iteration Level ! Go deep, but focusing just on one thin slice § User stories § Narratives § Acceptance criteria and tests § Working software § Involve Subject Matter Experts and Stakeholders § User and exploratory testing § … Product Families Themes Feature Sets Features / Epics Stories © 2013
- 28. Non-functional requirements as… Acceptance Criteria As a customer, I want to be able to pay by PayPal, so that I can complete my purchase. [Acceptance Criteria] - payment confirmed within 5 seconds - handle 100 concurrent payments - encrypted redirect to PayPal … http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories © 2013
- 29. Non-functional requirements as… Acceptance Criteria As a developer, I want all connections to the database to be made through a connection pool, so that ??? Separate User Stories As a CTO, I want up to 50 users to be able to use the application with a fiveuser database license, so that I can minimize ongoing license costs. http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories © 2013
- 30. Non-functional requirements as… Acceptance Criteria [CONSTRAINT] Separate User Stories As the CTO, I want the system to use our existing Constraint Cards orders database rather than create a new one, so that we don’t have one more database to maintain. http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories © 2013
- 32. Story Anti-patterns § Is there any reference to business value? § Is your story too detailed. Is it “replacing” the conversation? Look out for these smells... § Do you have trouble prioritizing it? § Is it too small or too big to estimate? § Does it have implementation details and technical language? § Are you thinking *too* far ahead? § Is the product owner unable to explain the card to you? § Are you splitting it by process lines (analysis/code/test)? § Gold-plating? © 2013
- 33. Back to our basics © 2013
- 34. Key Agile principles ! Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ! We welcome changing requirements, even late in development. ! Business and IT teams must work together. © 2013
- 35. § Cohn, Mike § § References (2004) "User Stories Applied”, Addison Wesley, ISBN 0-321-20568Non-functional requirements http://www.mountaingoatsoftware.com/blog/non-functionalrequirements-as-user-stories § Sutherland, J (2007) User Stories Done Right http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/4A%20-%20User %20Stories%20Done%20Right.pdf § Wake, B (2003) INVEST acronym http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ § Meyer, Paul J (2003) SMART acronym "What would you do if you knew you couldn’t fail? Creating S.M.A.R.T. Goals". Attitude Is Everything: If You Want to Succeed Above and Beyond. Meyer Resource Group, Incorporated, The. ISBN 978-0-89811-304-4. § Jeffries, Ron (2001) Card, Conversation, Confirmation http://xprogramming.com/articles/expcardconversationconfirmation/ § Lawrence, R (2009) Patterns for Splitting User Stories http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ © 2013
- 36. How do you get the most out of your user stories? © 2013
- 37. Agile Project Management Make decisions, not documentation The best Agile requirements are the ones the team builds as they work. Mingle generates actionable project records from natural team collaboration. Learn More See how Mingle can help you make the most out of your user stories