User Stories Cheat Sheet A User Story represents a small slice of requirement which benefits the user or customer. A story can be defined like this: Card: As a user I want to function so that benefit Conversation: Captures details relevant to the implementation of the story, such as the tradeoffs we are making Confirmation: (aka Acceptance Criteria) - What would I check to make sure the story is Done A good story should be: Independent... of other stories so it can be prioritized solely by value, cost and risk Negotiable... so the team and Product Owner can discuss tradeoffs Valuable... to the users, so value can be the primary consideration in prioritizing, and so we are clear on why we are doing this Estimate-able... so we can better assess the return-on-investment, plan & predict, and make sure we really understand it. A Spike may be need to to estimate a story with a high uncertainty due to technical challenges or lack of knowledge Small... so it can flow quickly through our pipeline, with as few surprises as possible, and so it can be elaborated and discussed at the right resolution Testable... so we have a good way to know when we are done There are different ways user stories can provide value: User value - The best value possible - The user story increases the value of our product from the user’s perspective Feedback from users (e.g. demo or mockup to users) Feedback from PM Remove technical uncertainty Remove schedule uncertainty - Finishing this story gets us closer to our goal Enables us to deliver faster (e.g. refactor the database schema, invest in continuous integration...) - This is the worse type of value as users would prefer not to pay for this, and cannot provide an indication of priority relative to other user stories. These are not really user stories but rather engineering work items, and are best handled continuously alongside user stories, but when they accumulate and need to be managed, a portion of the team’s attention and effort will need to be allocated to these types of items While stories are the basic unit of requirement, a higher-level view is usually needed, and may include: Theme (a broad category of stories, such as monetization, mobile, SEO...) Epic - A large story representing a feature-level item, which is broken down into multiple user stories MMFs - Minimally Marketable Features which represent the minimum subset of stories in an epic which can be released and marketed to users. This level of requirements often is often managed and visualized at the enterprise level akin to the way user stories are managed by delivery teams. Note that an MMF may include Epics and/or vice-versa. A product’s first MMF is the MVP - The Minimum Viable Product Stories are kept in a single, prioritized backlog, which represents user stories we will probably start working on soon. As we get closer to working on the stories, we groom them, breaking them down and fleshing them out, so the delivery teams can pull them in. Story Grooming is the process of preparing stories to the point where they ready to be worked on by a delivery team. This is done continuously, so that stories are defined just-in-time, and so we don’t get into a situation where the team does not have enough work. Teams typically schedule one-hour meetings twice a week to groom stories. Product Owner, Developers, Testers, User experience designers, DB Admins... all take part in story grooming. Represents what the team commits to do for every story before it can be considered “Done”. It should include as much the team can reasonably do, and will minimize the waste incurred with items that are completed but not ready for release. Example of a Definition of Done: All acceptance criteria passing Checked into the main branch Tested as per test plan Demo’d to PM Increases unit tests coverage Code review + implement all identified changes required All bugs fixed and verified Added to release notes This should be created, used, and maintained by the team, and is team-specific. Personas are fictional characters created to represent the different user types within a targeted demographic, attitude and/or behavior set that might use a site, brand or product in a similar way. Using personas while defining a story can help the team focus on the need of specific users, instead of developing generic features which won’t be great for everyone. They also help us focus on a subset of the users, so we can get feedback earlier and develop products more gradually. Ideally, user stories represent thin slices which cut through all necessary architectural layers of the product. This way we can get the end-to-end feedback and have more chance of getting real value. Teams often use a checklist which represents what we commonly want to consider before we are ready to pull the story into our pipeline. DoR can include things like: Performance Scalability Supportability (log entries, monitoring & troubleshooting) Deployment (upgrade & rollback, any changes to the ) Compatibility (backward & forward compatibility with other systems and services) Dependencies to other systems/teams While not all items will apply to all stories, these are things we want to ask ourselves before we start working on a story so we minimize the change of omitting an important aspect of the story. Stories are sometimes broken down into tasks which are undertaken by individual members of the delivery team. Tasks are typically very small (less than half a day). Breaking down into tasks will often surface some questions about the requirements and the design of the user story. You can use the following patterns to break down stories: Break Workflow/Sequence into individual steps Simple before complex (UI, Logic, Formatting...) Manual before automatic Defer performance and scalability Subset of the data See links for more information on patterns Techniques for Breaking Down Epics to User Stories These include Story Mapping and Value Stream Analysis, among others. Story Mapping - This technique works best for epics which include a flow of work. The various activities which compose the epic are laid out in a linear sequence and fleshed out into user stories, listed by criticality. Another technique which can work well for the big picture, before we get down to the individual flow level is Impact Mapping, in the goal is broken down into players/stakeholders, then how, and then what. A highly simplified example might look like this: Splitting Stories Flowchart - http://www.richardlawrence.info/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf Twenty Ways to Split Stories - http://xp123.com/articles/twenty-ways-to-split-stories/ Splitting User Stories Guide - http://www.rallydev.com/sites/default/files/Splitting_User_Stories_Guide.pdf Story Maps in Practice - http://www.slideshare.net/chassa/2013-0509story-mapsagilemeetupbp Analysis in Agile is more than just User Stories - http://www.slideshare.net/kentjmcdonald/analysis-in-agile-its-more-than-just-user-stories-20934958 Book: User Stories Applied Book: Agile Requirements
{'wiki_source': 'wikibooks', 'other_info': "{'content_model': 'wikitext', 'language': 'en', 'title': 'Agile Software Engineering Cheatsheets/Agile Requirements - User Stories & beyond', 'type': 'text'}"}