User Stories

The features that will be implemented in a release are decomposed into user stories. They are in the form "As a [user persona], I want [to use the product for something] so that [it adds value]." A user story example for an online store is "As a shopper, I want to keep items in my shopping cart so that I can come back to it later." User stories define what people want from the product and tell you intent and value; they are based on user needs, so they should be derived from user surveys and workshops. User stories should not include a lot of detail, because when they are written, not much is known about the project. The user story is a record that someone needs to talk to the user about what needs to be included, not a description of everything that needs to be done. Details should be added when the story is broken down into tasks.

User stories may be too large and need to be divided. The above example may need to be divided into "As a shopper, I want to keep items in my cart when I log off so I don't need to add them again" and "As a shopper, I want to keep items in my cart while I shop so I can buy more than one thing at once."

The story size is estimated relative to other stories using points. A relative estimation process is used because people are generally better at making relative size comparisons than they are at estimating absolute size. Since story size is relative, points will not need to be re-estimated unless the story's size has changed compared to the other stories. Additionally, a relative estimation does not include duration, so that estimations of size cannot be misinterpreted as commitments to be finished by a certain time. Furthermore, points per iteration can be used to measure a team's velocity, which can be averaged to determine how much work they will be able to do in future iterations. Velocity is the average number of points that a team can complete in an iteration. The team uses its velocity when scheduling which user stories they will complete, so that they will not over- or underestimate their capacity.

User stories are prioritized by business owners, working with users - or user proxies - and the development team. Business owners prioritize items based on Business Value, Risk Reduction, and Penalty, while the development team prioritizes based on Technical Value and Risk Reduction. The development team is involved in prioritizing because some features, such as servers, might have no value for the business owner or user, but a lot of technical value.

Since consumer needs may change in form or importance, user stories can change in importance after the start of the project. Stories may be added to the product backlog during the project, prioritized, and placed into the next or successive iterations. New stories should not be added directly to an iteration in progress, as that would disrupt the team and give them too much to work on. Stories that are adding something beyond what the customer wants should be left until last, because enhancements are not important for the project, and waste time that could be spent developing extra functionality for the product.

Once they are organized, the team should estimate each user story's relative size in points. The entire team should agree on the size because all of them may have to work on the story once it is broken down into tasks. The team then decides if they can commit to completing the user story during the iteration. User stories should be tentatively scheduled up to 2 iterations in the future, so that the team can figure out what they need in the next iteration, check dependencies, determine if they will need anything from another team, and be ready to commit when the iteration starts. Planning ahead also allows the team to progress if they finish their user stories early. However, these plans should be flexible, so that if stories change in importance, new stories are added, or the team does not progress as expected, they can be changed without too much trouble.

User stories should not be assigned to people, because the team as a whole is responsible for implementing them. They are broken down into tasks at the beginning of the iteration, which are also estimated without making an assumption about who will perform them. This is because multiple people may be involved, or the designated people may be busy doing something else. The team should use their velocity from past iterations or similar projects, logical progression, and the relative importance of the user stories to plan which ones they will commit to completing in specific iterations.

At the end of the iteration, if the story has been completed and tested, the team has earned its points. A user story is considered completed if all the tasks it was broken down to were completed. However, if one task is incomplete, the entire story is incomplete. This gives a clearer indication of where the team is than if it has a lot of 90%-completed stories.