User stories are short, simple descriptions of a requirement told from the perspective of the person who would like a new feature. They typically follow a common template that is used to foster alignment with the work at hand and is not limited to tech or agile teams.
In this article, we will cover:
- User Story
- Acceptance Criteria
- Prioritization
- Stretch Goals
- Notes
- Estimations
Do keep in mind that anyone can write a user story and not just PMs. But note that who writes a user story is far less important than who is involved in the discussions of it.
TL;DR — If you would like to skip to the complete user story template that you can copy and paste for your own projects, scroll down to the end.
As a <type of user>, I want <to perform some task> so that I can <achieve some goal>.
The beauty of this sentence is that it concisely summarizes:
- Who it’s for
- What is being built
- Why it’s being built
Having a shared understanding is key for cross-functional teams. And user stories help achieve this. They should be written in a simple way that can effectively communicate the main points across to the team — from developers to designers and testers to business.
Another importance worth noting is that user stories do not include how something should be done. As long as the requirements and acceptance criteria(s) are clear, this allows the experts in your team to have creative freedom in doing what they do best.
Given that <some context>, when <some action is done>, then <such outcomes are expected to occur>.
What I love about this sentence is that it asserts the results of what’s supposed to happen when certain conditions are met. This is the definition of done. Use this format to clarify assumptions so that there are no surprises.
Acceptance criteria explain what has to be done for the user story to be marked as complete. They’re commonly referred to as scenarios or detailed explanations of what has to be done. You can have multiple scenarios per user story.
Photo by Aw Creative on Unsplash
Is this important and urgent or important and not urgent?
Is this feature a must have, nice to have, or could have?
Is this high impact and low effort or low impact and high effort?
Prioritization is an art and science. Depending on what tool you use, you probably have seen the following matrixes or something similar.
Prioritization Matrixes
If you’re not sure what your team should focus on, set up a discussion using one or more of the frameworks above. Visualize the priorities by placing the tickets into a pile and assigning them to the respective quadrants.
By the end of the exercise, you should have a better idea of what to do now, what to do later, and what to do never.
What about stretch goals, notes, and estimations?
Good question!
Stretch goal is an additional goal that is optionally set for the user story. If you get around to doing them, great! If not, no problem. They’re meant to be inspirational challenges that will push your team to greater heights.
Stretch goal? Challenge accepted.
Notes are … well, notes. Sometimes when you’re writing user stories, you have extra information that might be useful for the person who picks up the ticket. Use this section to add comments or helpful references as bullet points.
Estimations or story points are used to estimate the difficulty of implementing a given user story. Scrum masters or product owners use this to measure velocity or the amount of work finished by the team in each sprint. It becomes an important metric used during retrospection and sprint planning because eventually, we will see the capacity of what can realistically be done within a certain timeframe.
Fibonacci numbers (1, 3, 5, 8, 13, 21, …) are frequently used to provide estimations because it forces teams to provide relative estimates. For example, it’s easier to distinguish five vs eight then five vs six. There are many creative approaches to providing estimations like using dog breeds or vehicles. I personally like using t-shirt sizes.
Story point estimations with t-shirt sizes
TL;DR
User Story Template
Title: <What this user story is about>Story
-----
As a <type of user>,
I want <to perform some task>,
so that I can <achieve some goal>.Acceptance Criteria
--------------------
Scenario A: <What should happen>Given that <some context>,
when <some action is done>,
then <such outcomes are expected to occur>.Stretch Goals
--------------
<optional>Notes
-----
<optional>Priority: <Highest, High, Medium, Low, Lowest, Unprioritized>Story Points: <1, 3, 5, 8, 13, 21, ... >
—
Example (*)
Title: Returns and exchanges go to inventory.Story
-----
As a store owner,
I want to add items back to inventory when they are returned or exchanged,
so that I can track inventory.Acceptance Criteria
--------------------
Scenario 1: Items returned for refund should be added to inventory.
Given that a customer previously bought a black sweater from me and I have three black sweaters in inventory,
when they return the black sweater for a refund,
then I should have four black sweaters in inventory.Scenario 2: Exchanged items should be returned to inventory.
Given that a customer previously bought a blue garment from me and I have two blue garments in inventory and three black garments in inventory,
when they exchange the blue garment for a black garment,
then I should have three blue garments in inventory and two black garments in inventory.Stretch Goals
--------------
- How can we automate the exchange or return process?Notes
-----
- We currently process returns by ...
- We currently process exchanges by ...Priority: MediumStory Points: 8
That’s it!
Having a shared understanding of the problem you’re trying to solve is critical to the success of any cross-functional team. Writing clear and compelling user stories is one way to reach such alignment. Take it a step further and treat it as a common source of truth to guide your team towards one goal, one direction.
Use it to express why we do what we do.
