Being busy isn’t always the same as making progress towards an important goal. To make progress, the team has to know what to work on, why it is important, when one task is done and it’s time to move on to the next. The team also has to know what is the next most important and valuable thing to work on so they are always delivering the most impact to their end users. Using user stories estimated based on risk and complexity that are ruthlessly prioritized using that that information is the best way we’ve seen to consistently and predictably deliver value forever.
In this article, you will learn to:
A user story is a short, simple description of a product feature told from the perspective of a user. It helps a team to understand what the feature is, who it is being built for and why it is valuable to build.
Anyone on a team can contribute stories, although it is typically the product manager’s responsibility to maintain and prioritize a healthy backlog of user stories. This includes writing and prioritizing enough user stories for a team to work on during a 1 or 2 week sprint or iteration of work. Learn more about the product manager’s role on the team in our Balanced Teams article.
Stories are designed to help collaboration. Unlike weighty requirements documents, user stories capture just enough information for a team to start talking and working together. We sometimes say that a user story is a “placeholder for a conversation”.
User stories help break up software development into small, valuable increments. Building software incrementally, and prioritizing the work that delivers the most value reduces risk and helps a software team plan and get rapid feedback on what they are building.
A story’s position in the backlog makes its priority clear; the most important story is at the very top while the least important story is at the bottom. This makes it obvious which activity the team will work on next. A team’s backlog is prioritized based on input from users, stakeholders and the development team. When prioritizing, they’ll consider user value, business value, development risk and dependencies.
Finally, a user story provides a common way to talk about the goals, motivations, and definitions of success of your end users. By carefully crafting user stories based on an understanding of your users, you are more likely to build something that delivers value to them.
Write user stories in a consistent manner that provides the team with enough context.
Common parts of a user story include:
The title is a short description that explains the content of the story at a glance and is written from the perspective of a target user. The user might be a real human, a generalized persona, or even another software system.
The main description of a story should explain which type of user wants the feature, what it allows that user to do, and what outcome or benefit this brings about. An established format is:
type of user
benefit for the end user
situation or context
some action is carried out
Acceptance criteria is important because they clearly describe when the story is done. Without an explicit statement of “done”, the feature risks scope creep. In the above example, the feature is done when the sales proposal downloads to the user’s computer as a PDF file.
Would it be handy if the user could email the PDF directly from the product? Sure!
Would it be great if the system would automatically prompt the user to follow up with the prospective customer in one week? Heck, yeah!
But, those features are out of scope for this story. The team should create new stories for those features with their own explicit and focused acceptance criteria.
Attach anything else helpful explaining the story including mockups, sketches or user flows.
Here is a complete example:
Simply put: people are bad at estimating how long it will take to complete tasks. Yet most people insist on estimating task completion based on time. We recommend estimating tasks based on risk and complexity rather than time to completion.
Agile software teams use estimation to understand the relative complexity of delivering a story. They do this because:
When discussing a story, usually in an iteration or sprint planning meeting, teams will estimate the size of a story in terms of story points. Story points measure a story’s complexity and risk. Teams use different scales. For example:
We use scales rather than time estimates because time estimates are known to be highly error prone. They do not account well for the uncertainty that teams often encounter when building software. Time estimates are especially prone to planning fallacy and optimism bias.
Relative complexity means thinking about similar stories that the team has delivered in the past and making a relative estimate. This way, the team can build up a consistent, shared idea of what constitutes a small, medium or large-sized story.
When team members give different estimates for a story, this can give rise to valuable conversations! Estimation prompts team members to talk about their assumptions and arrive at a shared understanding of what is involved in the work. Learn more in our short guide to estimation.
“When is it going to be done?"
– Your boss
Every team responsible for a deliverable has been asked this question.
Project teams commonly need to gauge how long it will take to deliver their work. Yet haven’t we just stated that we don’t recommend estimating work based on time to delivery?
Estimation gives the team data which helps them learn how to deliver more predictably over time and make predictions about future delivery.
To do this, we use the concept of velocity. You can calculate velocity by taking an average of the story points delivered in previous iterations. Once you know how many story points are left in your backlog, you can use your team’s velocity to forecast approximately how many iterations it is going to take to deliver the rest of the work.
Of course circumstances change and unexpected things happen, so predictions are never going to be 100 percent certain. To accommodate for risk, use a range of estimates based on optimistic and pessimistic scenarios.
If the number of story points a team delivers varies widely across multiple iterations, then the team’s velocity has high volatility. This makes it harder to predict delivery. It’s worth taking time with your team to understand why volatility is high and try to address it. Even uncertain estimates help to reduce and communicate risk, and make software delivery more predictable. Again, predictability and consistency are more important than raw numbers, and enable more accurate future planning.
Find out how to run an iteration planning meeting, where your team will estimate and discuss user stories.
Learn more about user stories in User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton.