User Stories
A User Story is a concept generally associated with "extreme programming" (XP) practices. It is intended to succinctly capture the idea of something valuable that is intended to be "done" to product ("done" here usually means something added to, changed, or removed from a software product). While user stories can describe very, very large functions or features (often called "epics"), user stories as used by Scrum teams are reduced in size and complexity until they are quite small and describe a simple and easily understandable addition or change.
Purpose
User Stories are important because they deliberately limit how much analysis is done and at what time in the development effort. Instead of attempting to learn everything there is about everything we think we're going to add to a product during the course of a Sprint, User Stories give us the means to stick to high-level needs and high-level descriptions. We then use the intervening time from the beginning of the development effort until the Sprint in which a story is actually built by a Scrum team to progressively elaborate the story, determine the details, and slice the story into smaller stories, carving out the unwanted complexities and risks.
Practices
There are a number of practices that are important when we include the use of user stories in our Agile development efforts (recommended). Here are some of the most critical practices:
- Bucket Budgeting - this practice helps us with user stories at the release planning level, determining estimated effort.
- Intake Estimation - this practice helps us with rapid estimation of user stories when they are received from customers or stakeholders.
- Baselining - this practice is necessary when a team needs to either begin using Story Points, or needs to reset their Story Point baseline due to significant changes in team staffing or skills.
- Triangulation - this practice helps us consistently estimate user stories by giving the team stories to compare with. Stories "bigger than the 1 point stories" but "smaller than the 5 point stories," will lead the team to estimate the story somewhere between 2 and 4 (inclusive).
- Story Slicing - this practice helps us reduce the size, complexity, and risk of a story by slicing it into smaller, easier to understand pieces.
- Story Estimation (Story Points) - this practice helps us quickly estimate user stories of all sizes
- Backlog Grooming - this practice helps Scrum teams reduce the size and complexity of the backlog prior to committing to stories in a Sprint.
- Planning Poker - this practice, created by James Grenning, gives teams a fun way to quickly and accurately estimate user story size and complexity.
See Also
