What is a user story? Is it the same as a business requirement? A user story is written by the customer, or from the customer’s perspective, and describes how they would like to interact with a product or solution. User stories provide important context and often express a desire for functionality that does not yet […]
A user story is written by the customer, or from the customer’s perspective, and describes how they would like to interact with a product or solution. User stories provide important context and often express a desire for functionality that does not yet exist.
User stories are very different from requirements. Requirements tend to prescribe a specific implementation or solution approach; they are often “closed” and provide little information about the user and their needs. Effective user stories center on the user and are deliberately open-ended. They intentionally keep the team focused on the problem space, allowing them more creativity and flexibility in how they address the user’s need.
User stories are intended to be placeholders for a conversation; they are like pointers to data and not the data itself. User stories should provide enough detail to allow team members to understand the context and the need, but they should not be overly specific. If they are, they will hinder creativity.
Ideally, a user story leverages the three C’s: card, conversation, and confirmation. It’s written on an index card (keeps it from being overly verbose); it prompts a conversation; and, when it is done, the functionality can easily be confirmed.
By reviewing a story and conversing about it, team members will conceptualize the need and develop a sense of the associated effort, complexity, and uncertainty. In some teams, this leads to a sizing effort. In others, it may lead to a more nuanced discussion. Regardless of the specific approach, well-drafted user stories and the conversations about them allow team members to decide whether to take the story on, address risks through a spike, or break the story up into incremental deliveries.
Teams should track and visualize all their work, however, that does not mean everything should be a user story. A good indicator is whether or not the work requires a conversation.
Should you, for example, write a user story about powering up your laptop in the morning? Probably not.
What about rewriting the build script for your team’s CI/CD pipeline? Probably so. The whole team should have the opportunity to talk about a big change like that.
What are some user story templates that teams find helpful?
A common format for a user story is:
“As a __________, I need ___________ so that __________.”
The most important pieces of this structure are the “so that” (why do I need this?) and the “as a” (who am I?). These add valuable context that can influence the approach to implementation.
For example, consider the following:
It’s easy to see how a conversation can help address questions, draw out misunderstandings, and provide even more valuable context.
User stories are often augmented by acceptance criteria, details that help ensure a story has been delivered correctly. These can be written as Given-When-Then statements. Given-When-Then is a core aspect of Behavior Driven Design (BDD).
Here is a simple example:
This format is particularly useful for determining when a story is done. Tools can help by processing Given-When-Then statements and turning them into automated tests.
If Given-When-Then proves overly prescriptive, acceptance criteria can be written more directly:
As with any practice, it’s all about what works best for a particular team.
Let us know your thoughts on user stories! How are you using them with your teams?
In this issue of Agile eXamined, Dan Greenberg looks at the intent and objectives of...
Backlog refinement and spikes are both about reducing uncertainty and they often lead to the...