IMPLEMENT PHASE
User stories
Detail the features you’ll develop in informal, plain language descriptions of user interactions. This will keep the work user-centered and focused on the overall vision.
Templates
No template needed
Who’s involved
Anyone on the core team can write stories, but the product owner is responsible for their quality and prioritization
Timeframe
When you’re building or iterating on a digital product
How to use this method
User stories describe the requirements of a working digital service from the perspective of the user. To ensure your user stories align with the project POV and make sense to the developers who’ll use them, follow these steps:
1. Define value
Start user story sessions by talking about the value of this work and how it’s related to your overall product vision. This helps orient the team and keep the big picture in mind.
2. Write a story
Fill in the blanks on this format to ensure stories are written from a specific point of view — whether focusing on the user, a set of users, a system, or a stakeholder:
AS A… [persona/system/service]
I WANT… [some action or behavior]
SO THAT… [value or need is met]
3. Set acceptance criteria
Provide details about how a feature should behave. Follow this format to add enough detail to each story that engineers understand the desired behavior and the team has a shared definition of done:
GIVEN… [provide context]
WHEN… [an action is taken]
THEN… [the desired result follows]
4. INVEST
Review your story to make sure it follows INVEST principles:
| Principle | Description | |
|---|---|---|
| I | Independent | The story isn’t subject to external dependencies or other stories when possible. |
| N | Negotiable | A story isn’t a requirements document, it’s an invitation to a conversation about how to meet a user’s needs. |
| V | Valuable | Every story should be helping to deliver value to our users or the team. |
| E | Estimable | The team should have enough knowledge about how to execute against this story to give it a rough estimate. |
| S | Small | Writing small stories keeps iterations short and feedback loops. fast |
| T | Testable | A testable story means the team can demonstrate the story is done. |