Downloaded 457 times
Uploaded byShriKant Vashishtha
How to Break the Requirements into User Stories
The document discusses how to break down large requirements into smaller, independent user stories for agile software development. It recommends following the INVEST principles to create user stories that are independent, negotiable, valuable, estimable, small, and testable. Some patterns for splitting large stories are also described, such as breaking stories into workflow steps, major efforts, business rule variations, and operations. The goal is to create functional pieces that deliver business value iteratively in a manageable way.
In this document
Powered by AI
Discusses why breaking down requirements into small user stories benefits project management.
Introduces the INVEST principles for effective user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Highlights the key team members involved in creating user stories: Business Analysts, Product Owners, and Iteration Managers.
Outlines structured patterns to create user stories across various scenarios, focusing on independence, value, estimability, and testability.
Details more patterns for user stories, emphasizing operations, deferring complex operations, and establishing acceptance criteria.
Addresses common pitfalls to avoid in user story development and emphasizes the need for clarity and focused functionality.
Provides resources and references for additional reading on user stories and effective project management practices.
More Related Content
Similar to How to Break the Requirements into User Stories
How to Break the Requirements into User Stories
- 1. How to Breakthe Requirements into User Stories - By ShriKant Vashishtha http://sampreshan.svashishtha.com
- 2. Why do wedo this… • To have small and independent functional pieces which deliver business value so that we can deliver iteratively. • Makes it more manageable and easier to predict. • It’s easier to identify and eliminate waste (anything that does not provide immediate value to the customer.) • It lowers project risk by increasing accuracy of estimates and thus predictability
- 3. Why do wedo this… • Completing small stories gives a better indicator of true progress • It creates better rhythm in the iteration • It gives the opportunity for the Product Owner to manage the priority of story functionality within a bigger story
- 4. Characteristics of Idealsmall functional piece INVEST Principles • I – Independent – (Stories are easiest to work with if they are independent. That is, we'd like them to not overlap in concept, and we'd like to be able to schedule and implement them in any order) • N – Negotiable – (It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details.) • V – Valuable – (We don't care about value to just anybody; it needs to be valuable to the customer. When we split a story, we're serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers.) • E – Estimable – (We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. ) • S – Small – (Good stories tend to be small. Stories typically represent at most a few person-days worth of work. Above this size, and it seems to be too hard to know what's in the story's scope. Smaller stories tend to get more accurate estimates.) • T – Testable – (If a customer doesn't know how to test something, this may indicate that the story isn't clear enough, or that it doesn't reflect something valuable to them, or that the customer just needs help in testing. )
- 5. Who is involved… •The core team which includes – Business Analysts – Product Owner – Iteration Manager
- 6. How to actuallydo it?
- 7. Pattern 1: WorkflowSteps “As a content manager, I can publish a news story to the corporate website.” can include the following independent stories • I can publish a news story directly to the corporate website. • I can publish a news story with editor review. • I can publish a news story with legal review. • I can view a news story on a staging site. • I can publish a news story from the staging site to production.
- 8. Pattern 3: MajorEffort “As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Express.” can include the following valuable and small stories • …I can pay with one credit card type (of VISA, MC, DC, AMEX). • …I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented).
- 9. Pattern 4 :Break out with a Spike “As a user, I can pay by credit card.” can include the following estimable stories • Investigate credit card processing. (time boxed) • Implement credit card processing.
- 10. Pattern 5: BusinessRule Variation “As a user, I can search for flights with flexible dates..” can include the following testable "business rules” • as “n days between x and y.” • as “a weekend in December.” • as “± n days of x and y.”
- 11. Pattern 6: Operations(e.g. CRUD) “As a user, I can manage my account.” can include the following independent user stories • …I can sign up for an account. • …I can edit my account settings. • …I can cancel my account.
- 12. Pattern 7: Deferfancy operations “As a user, I can search for flights between two destinations.” can include the following valuable user-stories • …using simple date input. • …with a fancy calendar UI.
- 13. Pattern 8: AcceptanceCriteria • Often it is possible to limit the user story to the happy day scenario only • And deal with exceptions, error cases or other special cases as different story.
- 15. Avoid Cause andEffect Trap
- 16. Ask why alot
- 17. Fully featured vsfully functional
- 18. References… • http://neilkillick.com/2012/03/22/why-should- we-make-user-stories-as-small-as-possible/ • http://rslawrence.wpengine.com/wp- content/uploads/2012/01/Story-Splitting- Flowchart.pdf • http://www.richardlawrence.info/2009/10/28/pa tterns-for-splitting-user-stories/ • http://blog.xebia.com/2010/04/01/fixing-the- cause-effect-trap-in-user-stories/
Editor's Notes
- #9 Sometimes a story can be split into several parts where most of the effort will go towards implementing the first one.
- #10 Sometimes a story can be split into several parts where most of the effort will go towards implementing the first one.
- #12 CRUD – create, retrieve, update and delete
- #13 CRUD – create, retrieve, update and delete
- #14 Add example of the user story
- #16 User story has following format:As a <stakeholder role> I want <functional piece> so that <business value> A lot of times, in this whole user-story statement everything becomes very clear except the definition of business value itself. Here’ an example:As a <user> I want <a button in the order screen> so that <I can go to the next screen>As translating the “so that” into business value becomes difficult, the user story gets into “The Cause-Effect Trap”. From the outset it looks logical, but the essence of why actually we started breaking down requirements into user-story is gone.
- #17 http://www.mindtools.com/pages/article/newTMC_5W.htmhttp://en.wikipedia.org/wiki/5_Whys
- #18 As you can see painting is fully functional and fully featured only at the end of all increments are done. Before that it’s neither of the two.Overall goal is not just being fully featured but being fully functional as soon as we can. In the iterative fashion that goal is achieved comfortably.So while creating user-stories from functional specs, it’s important to understand the bare minimal functionality which could be completed in the small span of time and still is usable by the customer. “It’s important to be fully functional but not necessarily fully featured”