A user story is a method of expressing a need or a problem in a way that gives the team solving the need or problem maximum flexibility in the solution they create. A user story also includes specific information that helps to clarify assumptions and prevent misunderstandings when developing a solution.
Even with that, many people don’t understand what user stories are and struggle to use them effectively.
User stories and their related acceptance criteria are a close as you’re going to get to a requirement or specification for most agile teams. That may make them sound like a poor substitute for the ‘hard requirements’ people are accustomed to using.
However, a big advantage user stories have over requirements is that user stories help you to have empathy for your customer.
Process vs Outcome
Traditional requirements can be very specific in both the desired outcomes and the process taken to get there. If you want a shelving unit and you buy a flat-pack, self-assemble shelf, you can see this in practice.
You want a shelf, and there are very specific instructions on how to assemble that shelf. The steps in the instructions tell you which pieces and parts to connect and in which order. And they even provide you a little hex-wrench to make assembly easier.
A user story approach backs away from the specifics and focuses more on the outcome. A user story doesn’t assume you want a shelf. A user story approach will focus on what outcome you want to achieve.
If you want to display your bowling trophies, you might have different needs from someone who wants to display their collection of antique first edition books, and they would have different needs from someone who needs a pleasing, staged background for their zoom calls.
Maybe all of those outcomes could be solved with the same flat-pack shelving unit assembled with the same parts in the same order. However, maybe the desired outcome is more important than the path you take to get there.
Maybe one person needs a table, one needs a room dividing screen and one needs a display case with glass doors.
With a user story approach, we work to understand the user, what they want to accomplish and why it is important. By taking this approach, the ‘who’, ‘what’ and ‘why’ are well understood, and the team creating the solution is able to work with minimal constraints and maximum flexibility and innovation.
Role – Goal – Reason (As a…I want…so that…)
“As a [role], I want to [goal], so that I can [reason]“
Role: The Who
The role is human with an un-met need. They are a real person who would like to see something different in the future from how it is today.
If that person is a user of your system, many teams will say, “As a user…”
This is a good start, but if it were more specific, it would be much more valuable. We often say, ‘user’, ‘customer’, ‘administrator’, etc. as though those descriptions are specific enough to help us understand the needs of person.
When I facilitate sessions on creating effective user stories, I like to help people learn the concepts by using examples that are universally understood. Experiences in restaurants create relatable examples, as do examples form online shopping.
Let’s consider two users who want to buy pencils. “As a user, I want to buy pencils, so that I have something to write with.” (not the best user story, but we’ll build on this)
What types of people buy pencils? People who work in offices use pencils. Children in school use pencils. Could there be differing personas (roles) buying pencils?
User 1 is a parent with a child in elementary/primary school. They need to buy a dozen pencils for their child because that is what the teacher has requested on the school supply list.
“As a parent of a primary school child, I want to buy a box of pencils, so that my child has something to write with.”
User 2 is the procurement officer for for a large school district. They need to buy enough pencils for all students in the district to take their end-of-year standardized tests.
“As the procurement officer for the New York City school district, I want to buy 1,000,000 pencils, so that students can complete their standardized end-of-year tests.”
Two users buying pencils, but with very different needs.
Make the role as specific as you can. Specificity uncovers additional needs and makes assumptions visible so they can be addressed.
Watch Areas: Role
Many well-meaning teams learn the user story format and use it all the time, even when it doesn’t make sense.
If you see, “As a developer…”, “As a scrum team member…”, “As a product owner…”, it is time to re-anchor on the purpose of a user story.
The format isn’t magical. The format allows teams to better understand the user being helped, what they want to accomplish and why.
Unless the members of the team will be the users of the final product, they shouldn’t be named in the user stories. Either rewrite the story from the perspective of an actual user, or admit that not every piece of work that a team undertakes benefits from the user story format.
If a certificate needs to be upgraded by the end of the month or your application will become unavailable to your users, then saying, “Upgrade certificate” is enough to get the job done. There isn’t any ambiguity in this task, nor is there a need for creativity. Sometimes work is just work.
However, these should be the exception, rather than the rule. The vast majority of work a team does can and should be stated in the user story format.
Goal: The What
Following the parent and the procurement officer in the pencil example above, the goal they want to accomplish can have a massive impact on the solution being considered.
For the parent, there could be different motivations behind the goal that could lead to different solutions.
As a parent, I want to… – buy a box of pencils – buy the specific brand of pencils requested by the teacher – buy the lowest cost pencils – buy colored pencils
Until we know more about their motivation (which comes in the reason/why portion of the user story it is hard to define the optimum solution.
Maybe the brand is most important; maybe price is. Maybe this is for an art class, so the pencils need to be colored drawing pencils. Imagine if we only gave them a way to buy a dozen #2 graphite pencils and they really needed a rainbow of colors. This is probably not the kind of thing that we want to learn once after we’ve launched our solution. This is why reviewing progress with your users and stakeholders every few weeks is the best way to avoid the pain that occurs when they see your final product and say, “Now that I see it, I realize I need something different,” but that is a discussion for another time.
Let’s expand on our second persona.
As the procurement officer for a large school district, I want to… – buy 1,000,000 pencils from our contracted vendor – ensure that the price I pay for 1,000,000 pencils is our negotiated contract price – ensure that 1,000,000 pencils can be delivered and distributed before end-of-year testing begins – etc.
Each of these goals creates a need to consider the problem from multiple angles and consider different types of solutions. This also demonstrates how being specific uncovers hidden needs and exposes assumptions so that you can address them in your solution.
Watch Areas: Goal
The goal portion of a user story is where traditional specs/requirements can creep in. If someone has adopted the user story format but not yet adopted the user story mindset, then the goal portion of the story can become a specific solution wrapped in user story language.
“As a parent, I want to add a box of pencils to my order using a blue button in the lower right hand corner of the screen and the button will be 12 point font and will say, ‘Add to Order’…””
Clearly this is an extreme example. Solutions pretending to be user stories can be subtle and unintentional.
“As a parent, I would like to start typing the brand of pencil I need in the search box and have it autocomplete what I’ve entered…”
This is a solution. Auto-complete, auto-suggest and even specifying it is a search box vs dropdown are examples of specific solutions. Solutions are the domain of the team. Solutions are the ‘how’ whereas user stories focus on the who, what and why.
In situations like these, find the word or phrases that identify a specific solution and work to rephrase the story without those words.
In the above example, ‘typing’, ‘search box’, and ‘autocomplete’ are specific solutions. A solution agnostic way to write this would be: “As a parent, I would like to easily find the pencils I need by using the brand name of the pencils…”
This formulation gives the team maximum flexibility on how to implement the solution. It also will lead to some great discussions during refinement on what ‘easily’ means and how to measure it via acceptance criteria.
Reason: The Why
“As a parent, I want to order a box of pencils with fast shipping, so that they arrive before school starts in 2 days.”
Speed of delivery and ease of ordering are more important to this parent in this example than price or brand. Optimizing a solution for speed of delivery would likely take you different direction from optimizing a solution so that best price is always the preferred option.
“As a parent, I want to order colored pencils, so that my child can be ready for their very first art class.”
The priority here is preparing a child for their first art class. What else might a parent want for the first art class for their child? Would it delight the customer to suggest a drawing pad to go with the pencils? Would that help them accomplish their goals?
“As a procurement officer for a large school district, I want to buy 1,000,000 pencils at our contracted price, so that we don’t go over budget for the year.”
The priority here is working within the budget, paying the contracted price and working with approved vendors. This means that giving them the right vendor and the right price is only part of the need. They will also need some indication that the vendor is their vendor and that the price is their negotiated price.
“As a procurement officer for a large school district, I want to buy 1,000,000 pencils and have them direct delivered to each school, so that we don’t have to manage distribution ourselves.”
The priority here is not with the ordering, it is with the distribution and delivery. In this user story, placing one order and having it parceled out to 1,400 individuals schools is the priority. In this case your solution may be focused on searching, usability and pricing, while the needs of the customer are in the areas of logistics and distribution.
Watch Areas: Reason
When the reason or ‘why’ is understood, it gives the team flexibility in the solution they provide and prompts them to ask themselves, ‘what else might this person need?’
That, ‘what else’ question is a slippery slope as it can lead to scope creep if the team gets more excited about the ‘what else’ ideas and loses focus on the original problem.
However, a team that asks, ‘what else?’ experiences empathy for their user. They are putting themselves into the shoes of their user. This is where I’ve seen excitement, innovation and intrinsic motivation take hold within teams. Once team members feel that it is their job to make things better for other people, instead of simply completing stories or solving some abstract technical puzzles, they begin to bring their own energy, excitement and commitment to what they do.
Be on the lookout for the energy that is generated when the team understands the ‘why’. This is goodness. Also ensure that the ‘why’ doesn’t cause the team to loose focus on the goals of the product or initiative.
And, without a solid ‘why’, the solution you choose can have vastly different consequences as explained here.
The Additional Arts: Splitting and Sizing
Once a team learns how to write effective user stories, they still need to challenge themselves that each story is as small and simple as it can be. And they still need to discuss and refine the story to ensure everyone on the team understands the risk, complexity and effort that might go into this story. This often leads to adding story points to the story.
The first concern is story splitting, the second is story sizing.
For lots of great info on writing and splitting stories, see this article and the flowchart embedded at the end.
Here are some additional thoughts and links about creating simple and effective user stories.
For refining and sizing stories, that will need to be a topic for another time.
Conclusion
User stories are a compact way to convey the ‘who’, ‘what’ and the ‘why’ of a problem or an un-met need. When they are focused and specific, they clarify assumptions and prevent misunderstandings and allow the team to work with minimal constraints, and maximum flexibility and innovation.
Creating good user stories is a skill that everyone on a team must develop, not just the product owner. Splitting and sizing well written stories are also critical, learnable skills.
Happy story writing!