Capturing high-level requirements is a crucial part of agile development frameworks like Scrum and Extreme Programming (XP). A user story allows teams to understand those requirements by framing them as a short, simple description from the end user’s perspective.
Any product manager knows just how critical writing good user stories is in ensuring a product's success. But it’s also pretty easy to make user story mistakes! So, in this guide, we’re going to give you the tools and knowledge you need to write clear, effective user stories.
The key questions we’ll answer are:
How do you write a perfect user story — what are the essential ingredients?
How do you structure a user story?
How to choose the right format for user story
User stories templates: Word or Excel?
Let’s get started!
Card, conversation, and confirmation is a formula created by Extreme Programming (XP) co-founder Ron Jefferies in 2001.
Jefferies looked to improve output by simplifying user stories templates, turning them into a tool that could be understood by anyone, including developers, stakeholders, and customers.
The 3 C’s framework gives us a user story template that captures the components of a user story.
Card - A card or sticky note is used to give a physical manifestation of the user story. This helps to cement the requirements in the team’s heads as there is a physical representation, rather than a hypothetical idea.
Conversation - This refers to the second stage of working with user stories: how to achieve the card’s requirement. Teams will discuss, ideate, and ask questions to develop a shared understanding of the situation, as well as potential solutions.
Confirmation - The final C refers to the process of solidifying plans to move forward. The team will use decision-making frameworks to figure out the optimal solution, taken from the Conversation stage to solve the requirements from the Card stage.
The 3 C’s framework covers the end-to-end process of a user story. The card offers a visualization of a real user pain point, which triggers a deep, meaningful conversation about how to solve that issue. The final confirmation stage ensures that no user story goes unanswered and teams aren’t moving on to other tasks, leaving the user story unfinished.
User stories should incorporate agile principles, including:
The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Working software is the primary measure of progress.
Capturing user stories on cards is a great way to incorporate the 3 C’s into your agile working environment. As with other agile ways of tracking progress, cards can be easily moved around to clearly indicate priorities.
Agile user stories are prioritized and visualized with cards to ensure the entire team is aligned with the current goals.
The key to writing an effective user story is to determine the who, what, and why. To do this, you should follow the INVEST framework to ensure your user story touches upon everything that’s required.
Let’s quickly look at what INVEST represents.
Every agile user story must be independent and should stand on its own. User stories should be workable in any order as much as possible and you should be able to move a user story around the backlog. This is helpful when prioritizing, especially when dependencies come into play, as it may not be possible to implement a valuable story without implementing other much less valuable stories.
A user story should capture the essence of what is required from the customer’s viewpoint. It’s not a technical specification, but more of a conversation starter.
There needs to be a collaboration between teams and customers when implementing user story templates. The final deliverable should be created based on in-depth discussion and collaboration, and this is where the negotiation comes in.
As a collective, you must decide what can add value to the product and what should be left behind. This will help build something that is truly brilliant, rather than simply filling the checkboxes of the user story.
Every single user story should add value to the project/product. If any stories fail to have any discernible value, then they should be rewritten or scrapped entirely. With your user stories being prioritized in the backlog according to business value, it should be simple to spot anything that doesn’t add value.
A story has to be able to be estimated or sized so it can be properly prioritized. Being able to estimate a timeframe for user stories allows for better prioritization, as a valuable task that takes a long time to complete may be pushed to a lower priority level while the team focuses on high-value, fast-completion tasks.
When estimating agile user stories, you should be able to easily distinguish between high and low-effort stories. If a user story cannot be estimated, it should be rewritten in a way that makes the scope of the story clearer. You can also look at splitting a user story into multiple stories to help improve clarity.
User stories are not technical specifications, nor are they detailed accounts of customer pain points. As we mentioned earlier, they should simply capture the essence of customer requirements. Stories are gateways to further discussion and shouldn’t replace the discussion itself.
One of the best indicators that you’re writing effective user stories is testability. Every story needs to be testable in order to be “done”. To achieve this, try writing the acceptance criteria before implementing the user story.
Once you’ve got to grips with the 3 C’s and the INVEST framework, it’s time to write your user story! Let’s break down that process into simple steps.
In order to write an effective user story, you first need to identify and define the user. Who will be using your product?
A helpful trick to help you visualize your user is to create persona profiles. A user persona is an archetype or character that represents a potential user of your website or app.
Creating a persona essentially gives you a fictional person that represents the needs of your customers. Add their relevant attributes, attitudes, and behaviors to help give context to the voice of the customer and any customer-focused decision-making. It also helps to give the person a name and find them a photo to create a sense of a real person.
Now you have your user persona, it’s time to dive into the detail. What exactly does your customer expect, need, or want from this product?
This step will require you to look at market research and customer feedback to identify real needs, rather than assumptions about your user needs. You can also refer to the “goal” section of your persona profile, then add a brief description of this to your story.
Put yourself in your user's shoes for a moment. What benefits will they receive from this item?
For this stage, it’s also helpful to ask the question “why will customers choose our product over our competitors?”. This will help everyone to understand the value of that user story and help with prioritization.
In agile, teams are required to deliver products that are potentially shippable. Acceptance criteria is the clearest and quickest way to determine whether a user story is done or not.
Each user story should have at least one acceptance criteria but try not to list too many. You can use S.M.A.R.T objectives to ensure your criteria are measurable. Always remember to write from your end user’s perspective and not confuse acceptance criteria with a to-do list.
The card represents 2–3 sentences used to describe the purpose of the story.
The card is usually in the following format:
As a <Role> I want <goal>so that <benefit/expected outcome >
The written text must address the “who (role)”, “what (goal)” and “why (benefits)” of the story.
The collaborative conversation facilitated by the product owner involves all stakeholders and the team. This conversation is mostly verbal, where a detailed description of the user story is discussed. The written Card is modified to reflect the current shared understanding of this conversation.
Confirmation represents the acceptance criteria, which is how the product owner will confirm that the story has been executed to their level of satisfaction. Confirmation represents the conditions of satisfaction.
This starter template will help you write user stories and acceptance criteria and organize them in one easy-to-read view. You can also add details like a priority and estimated effort.
Some agile teams use epics to group related user stories into a larger category. This user story template will help you capture epics and user stories in one place.
Themes are at the top of the agile work hierarchy — above epics and user stories. They represent major investments in strategic initiatives and convey how you intend to make progress toward your overall business goals.
With this user story template, you can keep your strategy top-of-mind during the development process by associating your user stories with different themes. You can also add a column to include your epics if you use them.
Teams practicing certain agile methodologies may prefer to include additional details when writing user stories. For example, organizations that implement SAFe® often add in the benefit hypothesis, nonfunctional requirements, and cost of delay.
Here is a more detailed user story template that aligns with SAFe® methodology:
With the majority of user stories templates being some form of a table, Excel may be the first place that teams go when it comes to creating a user story template of their own. But while it’s easier to build a table in Excel, it’s not the most user-friendly program in the world.
User stories may need to be rewritten as specifications and user needs change, so you need to build your user stories in a program that allows for quick, simple edits. And that’s why some teams prefer to use word processing software for user stories than a spreadsheet database.
To learn how airfocus can help you with user stories and story mapping, download our free 5-minute guide.
Just want to dive into the work? Be sure to check out our great template library for a quick start to all things product management!