![USER STORY TEMPLATE As a… [user] I want to… [goal] So that I can… [motivation]](https://cdn.prod.website-files.com/649220d2911fb5552e5aca5e/64a478d8a5de6a0b421972ed_6369353a74465b912b6cbd63_User%2520Story%2520Quote%25203%2520-%2520Template.jpeg)
.svg)
.svg)
If you are a designer, developer or have any other job where you create something, then an essential part of your job is solving problems and delivering solutions.
Are you motivated by creating things that help people? If so, you will want to deliver not just what people ask for but what they want and need.
And that’s why you need to understand the simple but powerful tool of user stories.
User stories aren’t unique to Scrum, but it’s where people often first encounter them. They seem simple in their structure, but commonly I hear people ask:
How does a user story work in Scrum? Am I doing it right?
You can learn to write user stories both for your Scrum backlog and many other applications. This article will cover three essential topics to help you feel confident writing user stories.
- What are user stories in Scrum?
- User story template and examples.
- How to use user stories in Scrum.
- Estimating user story size.
- Discover uses for user stories outside of Scrum.
- User stories and acceptance criteria.
- Additional user story resources.
What are user stories in Scrum?
Have you ever heard someone say, “This is what I asked for but it’s not what I wanted.”
It’s so deflating. All that work going towards creating the wrong thing.
I know the frustration of putting in the hard work to design a website or a room in a home just how it was asked for, only to discover later there was a mismatch in what they needed or wanted, which was never communicated.
It’s not fun.
But I've had a lot less of those since I've begun applying user stories both to work and across the various domains of my life.
By using user stories, you can say goodbye to the wasted time of working on the wrong thing.
Requirements can be hard to write well, and you will face questions like:
- Should I focus on form or function?
- Should I write the requirements in terms of business goals, technology, or user experience?
User stories are a schema that helps us order the requirements around the end user's needs, motivations, and goals.
Focusing on the end-user is critical in product development. They are who we are designing for. User Stories is a straightforward tool that will give you the confidence you're building the right thing.
User story template and examples.
A user story breaks down the outcome into three statements, each written from the user’s point of view.
- As a… [user]
- I want to… [goal]
- So that I can… [motivation]
Let’s look closer at each statement.
As a…
“As a…“ identifies who the user is. The more specific, the better. You want to be able to envision the person who you are designing for.
A product designed for a tightly defined user can still be effective for a broad audience. But a one-size-fits-all product usually fits nobody well.
I want to…
“I want to…” identifies the goal. It’s the immediate outcome the user is looking for.
If you’re on a Scrum team, this is the outcome your team must deliver.
You must make it clear and frictionless for your user to reach their goal.
This section isn’t directly naming the deliverable. It’s naming the user’s action. So rather than “I want… a video on user stories,” it would be “I want to learn about user stories.” The latter focuses on their goal without prescribing the deliverable.
So that I can…
“So that I can…” identifies the motivation. It’s why the user wants the achieve their goal. When creating something, you must make multiple design choices along the way, and the user’s motivation should inform those.
When the solution doesn’t consider the user’s motivation, they can feel it’s a miss and end up frustrated. But if you nail the why, they will say things like, “this is exactly what I was looking for.”
So to review all of them together
- As a… [user]
- I want to… [goal]
- So that I can… [motivation]
Next, let’s look at a couple of examples.
Examples of user stories
If you were working through my What is Scrum Guide, maybe a user story for you could be.
- As a student studying project management,
- I want to understand the general ideas of Scrum,
- So that I can determine if something I want to pursue a certification in.
or maybe it's
- As a team leader,
- I want to understand the general ideas of Scrum,
- So that I can know how to respond to my boss means when she says she wants us to become agile.
or a more general example
- As an entrepreneur,
- I want a simple but effective way to organize all the stuff I need to get done,
- So that I can keep delivering the right things and not get bogged down or sidetracked.
As you can see, both user stories have the same goal, “I want to understand the general ideas of Scrum,” but different users and motivations. Those different motivations would nuance how I write posts and which next steps would be most helpful to offer.
Looking at just these two user stories leads me to not only write posts like What is the definition of Scrum? But also, Should I get certified for Scrum? and How to apply Scrum outside software development.
By using user stories, you can say goodbye to the wasted time of working on the wrong thing.
You and your team can go from delivering solutions that are in the neighborhood to ones that are on target.
If you’re on a Scrum team, you can know precisely what to deliver at the end of a sprint.
If you’re a designer, you can create things that delight people.
And all of us can use user stories to better solve problems in our everyday lives.
Related Guides
How to use user stories in Scrum.
Implementing user stories helps your team build on the 3 pillars of Scrum.
As the Scrum team writes a user story together, it forces shared transparency and clarity about who they are creating for and why. They can then inspect their work against their user stories and make adjustments to meet both the users' goals and motivations.
Stories define the work being done to meet the requirements of the user. While the whole scrum team participates in the creation and especially clarification of user stories, the product owner is accountable and responsible for the quality of the user stories.
When to write user stories in Scrum.
During the backlog refinement session, the Scrum team reviews all the items currently in the backlog. Each of these items should include a user story.
A straightforward user story will help the team identify what they will create and how it will relate to other product features. Stories for future sprints are continually reviewed and clarified as more is known about the projects.
These continuous adjustments to the user stories give the team greater agility as they adapt to ever-changing requirements and market dynamics.
The user’s motivation should inform how we meet their goal.
When a team gets high-level requirements, they decompose or break down those large requirements into smaller requirements, features, or stories.
If a story seems too big to complete in a single sprint, the team can ask, “What are the steps a user will take to complete their story?” That huge story may serve as an epic, which is a collection of related stories.
When to review user stories in Scrum.
At the end of a sprint, you will inspect your product increment during the sprint review to see if it fully satisfies the user story. This feedback is a great reason to invite users to the sprint review.
User stories are helpful in everyday life too.
The product owner must navigate and negotiate the tension between the development team’s input and the stakeholders’ input. They will accept new stories from the stakeholders and must prioritize them against the other items in the backlog.
Continually, the product owner balances the needs of the business, the needs of the users, and the constraints of getting it done.
Writing internal user stories in Scrum.
Sometimes the development team will need to spend time working on infrastructure or skills for future stories to be possible. These internal stories are also part of the sprint backlog, and the product owner will represent the need for these stories to the stakeholders.
Here’s an example of an internal story for a creative design team:
- As a creative team,
- We want to grow in competence in After Effects,
- So that we can keep up with all the motion graphic requests we’re getting.
These sharpening-the-saw types of user stories are critical for the long-term growth and effectiveness of the development teams. They often arise during a retrospective session when the team identifies how they can grow and improve.
In order for the team and the product owner to manage all these user stories, they need a straightforward method to determine how much work it will take to complete it.
By using user stories, you can say goodbye to the wasted time of working on the wrong thing.
Estimating user story size.
User stories are sized using story points. There are multiple methods for sizing user stories, and I walk through them in detail in my guide to using story points in Scrum. But I’ll cover the basics here.
How to use story points to estimate user stories
You probably have a lot to get done, so you need an effective and efficient way to quantify that workload.
Story points are simply a numeric value assigned by the team to a given user story. This value represents the amount of work required to complete the user story.
The two most common methods for quantifying story points are:
- The Fibonacci sequence.
- T-shirt sizes.
The Fibonacci sequence is the numbers you get when you start with 1 and 2, and then each subsequent number is the sum of the previous two. So the sequence looks something like this.
1, 2, 3, 5, 8, 13, 21, 34, 55…
T-shirt sizing is just what it sounds like.
XS, S, M, L, XL…
With both approaches, any value is about the size of the previous two values added together.
I want you to notice the method not being suggested here.
Hours.
Measure user stories in hours is a common pitfall teams fall into. This story points vs. hours dilemma leads us to the topic of relative estimation.
Relative estimation for user stories
It’s common for teams to face challenges when trying to estimate workloads.
There can be disagreement about how much work something will take, or teams can feel overwhelmed by the undetermined but significant amount of work on their list.
One of the critical challenges in estimating workload is that the traditional approaches are both personal and subjective.
Story points and relative estimation provide you with a better option.
Relative estimation or relative sizing is a method of measuring new workload relative to past workload. The relative measurement against previous user stories contrasts absolute measurements like hours spent or lines of code written.
Here are four steps to using relative estimating for story points on your team.
- You create a library of past user stories (or tasks if you’re new to user stories).
- Group together ones that were about the same size.
- Move some past user stories around until your groupings resemble the same relationship as the Fibonacci sequence. (a task from one group being about the size of two tasks from the two next smaller groups added together)
- When you have new work, you can ask, “is it more like this group of past work or that group of past work?”
You can find more examples, tips and tricks for relative estimation in my agile story points guide.
You can feel confident in how much work you have to do using a specific measurement for your workload without getting stuck in the weeds debating how many hours something will take.
Discover uses for user stories outside of Scrum.
User stories aren’t just for a Scrum backlog. They’re an excellent problem-solving tool for a variety of situations.
I use them when helping someone build a website to identify who will be coming to the site, what they are trying to accomplish and why.
After we have a list of user stories, I have them prioritize them. We then agree these top stories will be how we evaluate the site. If the primary users can reach their goals, the site is successful.
Once the first version of the site is complete, I’ll run some user tests on the site, asking people to do tasks related to our top user stories. User stories keep the client and me as the designer aligned to meet their customer's needs.
User stories are helpful in everyday life too. When we moved into our house, we needed a place for seven people's shoes, coats, and bags. I used user stories to organize everyone's competing goals and motivations. I could then use these stories to evaluate possible solutions in the different spaces of our home.
Anytime you’re trying to solve a problem or create a solution, user stories are a great tool to have in your toolbox.
Related Guides
User Stories and Acceptance Criteria.
Acceptance criteria and user stories are vital tools used in Scrum to describe the work to be done. Let's take a closer look at how they're similar, how they're different, how they work together and then look at some examples.
Both acceptance criteria and user stories have a simple but effective format. They both bring clarity to the value you’re creating for the end-user.
How is acceptance criteria different than user stories in Scrum?
Acceptance criteria and user stories fundamentally answer different questions. They each contribute complementing aspects of clarity.
- A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
- Acceptance criteria focuses on the actions taken by the user to meet their goal. It emphasizes the what of the new functionality.
Acceptance criteria and user stories are a dynamic duo of user-centric development.
How do acceptance criteria and user stories work together?
Because acceptance criteria and user stories answer different questions, when combined, they provide a fuller picture of the work that must be done.
The user story really comes first because it answers the why. If there is no why then the work isn't genuinely delivering value. But once the why is clear and identifies the user's goals and motivation, the team must answer the question of what. What will they create to help the user achieve their goal?
The acceptance criteria focuses more on how the interaction will be designed and what the end state will be.
Together user stories and acceptance criteria answer the questions of
- Did we build the right thing?
- Did we build it right?
Examples of using acceptance criteria and user stories together.
Here’s an example of using a user story from earlier in this post.
User Story
- As a student studying project management,
- I want to understand the general ideas of Scrum,
- So that I can determine if something I want to pursue a certification in.
Acceptance Criteria
- Given that I’m reading through the What is Scrum Guide,
- When I click the FAQ section,
- Then I see a question about certification without having to scroll.
This example also illustrates how you can apply the tools of user stories and acceptance criteria to creative work like content creation.
The user story is created first, and the acceptance criteria is built from it. They are a dynamic duo of user-centric development.
Action Plan
We covered a lot in this article. If you want to continue learning how to apply user stories in your work and everyday life, here are some great resources:
- How to use story points in Scrum
- Learn to forecast progress in Scrum
- A How to Guide for Writing Acceptance Criteria
If you want to learn about other elements of Scrum, here are a few articles to start with. If you want a deeper dive, check out my What is Scrum? A Guide for Everyday People to Learn Scrum or my collection of Agile how-to videos on Youtube. If you have more questions, please feel free to reach out on LinkedIn.
Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 30-minute coaching session, and we can work together to identify a good next step for you.
Frequently Asked Questions
Agile story points
What are story points?
They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.
Learn to use story points and explore the essential Scrum glossary.
Are Scrum story points measured in hours?
In Scrum, you are not measuring work in absolute terms like hours spent or lines of code to be written. Two reasons for this:
- Not everyone works at the same pace or has the same set of expertise and experience.
- Until you do the job, these are unknown and, at best just guesses.
The problem with absolute sizing using hours is you begin to measure the people, not the work. Relative sizing measures the new work against past work shared by the whole team. Instead, the work is sized relative to past work already completed. So when looking at a new user story, the team asks, “Is this user story A most similar to this past user story B or this past user story C?”
Learn other essential Scrum terms.
Do story points in Scrum always use the Fibonacci sequence?
The Fibonacci sequence is the go-to solution for many Scrum teams because it allows for relative sizing while still being a numeric measurement. It has two key advantages:
- Keeping story points measured in numbers is advantageous because it is then easier to calculate a team's velocity.
- The numbers have distinct relationship with each other making relative sizing more intuitive. The Fibonacci sequence increases such that each number is the sum of the previous two number.
Non-numeric options are still possible, and one of the most popular is using t-shirt sizing, like small, medium and large. Lean more about using story points or learn other essential Scrum terms.
What is velocity in Scrum?
This measurement allows the product owner to forecast when future features will be ready. It is calculated by averaging how many points the team has complete over the past few sprints.
Learn to forecast in Scrum using velocity and explore the essential Scrum glossary.
Scrum User Stories
What is a user story?
They keep the team focused on the value they create for the end-user and are written using the following format:
- As a… [user]
- I want to… [goal]
- So that I can… [motivation]
See examples of user stories to learn to write your own and explore the essential Scrum glossary.
What is acceptance criteria in scrum?
Acceptance criteria is written using the following structure:
- Given that [context allowing me to take an action]
- When [I take the action]
- Then [a result occurs indicating success or failure]
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
How are acceptance criteria and user stories different?
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
What's an example of acceptance criteria?
Acceptance criteria is structured using the template
- Given that [context allowing me to take an action]
- When [I take the action]
- Then [a result occurs indicating success or failure]
Here are 3 examples:
Checkout process functionality
- Given that I’ve added all the items to my cart and I’m logged in,
- When I click the check out button,
- Then the checkout page loads with all my payment and shipping information preloaded.
Advertising campaign
- Given that someone fits our ideal customer persona,
- When they search for keywords we’re targeting,
- Then a link to a compelling offer is displayed above the fold.
Marketing campaign (Did you know you could use Scrum for marketing)
- Given that a customer is already receiving email communications,
- When they visit the site and engage content related to a specific product,
- Then they will be automatically subscribed to nurturing campaign highlighting that product. Or
See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.
What are story points?
They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.
Learn to use story points and explore the essential Scrum glossary.
Scrum design
What are the three pillars of Scrum?
Scrum is founded on three essential pillars, and each leads the team to ask a critical question.
- Transparency. How does this make things more visible?
- Inspection. Where does this create space to evaluate?
- Adaptation. When does this encourage growth?
Learn how to apply the three pillars of Scrum and then explore the most common terms in a Scrum glossary.
What are the values of Scrum?
There are five values critical to the practice of Scrum: commitment, courage, focus, openness, and respect.
- Commit to achieving the goals of the Scrum Team.
- Courage to do the right thing and work on challenging problems.
- Focus on the Sprint's work and the Scrum Team's goals.
- Open about all the work and the challenges with performing the work.
- Respect each other to be capable, independent people
Learn how to align Scrum values with your organization and then explore the most common terms in a Scrum glossary.
What is the sprint goal in scrum?
The sprint goal encapsulates the product owner’s vision into a concrete statement for the development team to measure the sprint against. The sprint goal provides a theme for the sprint’s work helping the team see how all the parts come together.
Learn more about the role of the sprint goal in scrum and explore the essential Scrum glossary.
Acceptance criteria
What's an example of acceptance criteria?
Acceptance criteria is structured using the template
- Given that [context allowing me to take an action]
- When [I take the action]
- Then [a result occurs indicating success or failure]
Here are 3 examples:
Checkout process functionality
- Given that I’ve added all the items to my cart and I’m logged in,
- When I click the check out button,
- Then the checkout page loads with all my payment and shipping information preloaded.
Advertising campaign
- Given that someone fits our ideal customer persona,
- When they search for keywords we’re targeting,
- Then a link to a compelling offer is displayed above the fold.
Marketing campaign (Did you know you could use Scrum for marketing)
- Given that a customer is already receiving email communications,
- When they visit the site and engage content related to a specific product,
- Then they will be automatically subscribed to nurturing campaign highlighting that product. Or
See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.
What is acceptance criteria in scrum?
Acceptance criteria is written using the following structure:
- Given that [context allowing me to take an action]
- When [I take the action]
- Then [a result occurs indicating success or failure]
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
How to write an acceptance criteria statement?
Acceptance criteria is broken down into three parts.
- Given that [context allowing me to take an action]
- When [I take the action]
- Then [a result occurs indicating success or failure]
Learn more about templates for writing acceptance criteria or learn other essential scrum terms.
How are acceptance criteria and user stories different?
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
How are acceptance criteria and the definition of done different?
Acceptance criteria is specific to an individual task, but the definition of done applies to all work done by a team. Acceptance criteria answers the question, “What will be true when this task is completed.” The definition of done answers the question, “What are we committing to do every time we complete a task?”
See more examples and learn to write acceptance criteria or learn other essential scrum terms.
Scrum backlog
What is the backlog in Scrum?
There are actually two backlogs, the product backlog and the sprint backlog. They each contain the definitive list of work to be done. The product owner keeps the backlog ordered by priority.
Learn to use the backlog in Scrum and check out the sprint backlog vs product backlog in Scrum.
How are the product backlog and sprint backlog different?
The product backlog prioritizes the features needed in the product. It is a singular visible source of requirements for the product.
The sprint backlog represents the work to do in a given sprint. It is a definitive list of all the scrum team is being asked to produce for the sprint.
Learn more about the sprint backlog vs product backlog in Scrum.
What is a PBI (product backlog item)?
Each item in the backlog represents precise work and value to deliver. Often these PBIs are written using both user stories and acceptance criteria. The PBIs are what gets refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.
Learn more about how backlogs are used in scrum, the sprint backlog vs product backlog in Scrum and explore the essential Scrum glossary.
What is the Scrum sprint backlog?
The Scrum sprint backlog is a prioritized list of items from the product backlog that the development team plans to complete during the upcoming sprint.
It is a plan for the Sprint and is created during the Sprint Planning meeting where the Development Team decides on how to build the functionality that meets the Sprint Goal. The Sprint Backlog typically includes user stories, bugs, technical work, and other items that the development team needs to work on during the sprint. Each item in the Sprint Backlog has a clear definition of done, so the team knows when the item is considered complete.
The Development Team is responsible for creating and updating their Sprint Backlog throughout the Sprint, making sure they are on track to meet the Sprint Goal. The Sprint Backlog is a working document that helps the Development Team visualize their progress and make any necessary adjustments to their plan as they go along. The Sprint Backlog is also transparent, allowing stakeholders to see what work is being done during the Sprint.
Learn more about the backlogs of Scrum.
What is the Scrum product backlog?
In Scrum, the product backlog is a prioritized list of features, bugs, technical work, and other product-related items that need to be addressed by the development team.
It serves as a single source of truth for what needs to be done on the product.
The items in the product backlog are ordered based on their importance to the product owner and the value they bring to the end-user. As the project progresses, the product backlog is constantly updated to reflect new priorities, changes in requirements, and feedback from stakeholders.
The product backlog is a living document that evolves throughout the project's lifecycle. It provides transparency and enables collaboration among all members of the Scrum team.
Learn more about the backlogs in Scrum.
