How to Write User Stories: A Complete Guide

User stories are a vital part of proper agile software development: Let’s look at their role and learn how to write user stories.

Agile frameworks are a popular, effective way to structure software development and delegate tasks. Writing user stories (not to be confused with how to write a testimonial) is a tool in agile development that allows developers to understand what needs to be done and how to fulfill a requirement. That makes them a very important starting place – but it also means they have to be constructed carefully. Here’s what you should know.

What is a User Story?

It’s a term used in software development within an agile framework. The user story is typically considered the smallest unit in the agile project or the first step in fulfilling a requirement. They are created when a project is fully planned out.

So, what exactly does that mean? Every software feature has (or should have) a particular purpose when it is added to a project. That purpose should influence its entire development and how it’s incorporated into the overall framework. Developers can reference this purpose whenever needed to make decisions, especially about how to break down goals and what to prioritize. The “user story” is simply a way to describe the purpose of a feature.

User stories are written from a user’s perspective, typically in just a sentence or two. They capture the user’s viewpoint and what that user wants to do. When completed, good user stories are an easy way to talk about strategic goals, what features can be safely discarded or should be added, and much more. You might be wondering, why write a user story?

How To Write a User Story

Step 1. Get Input 

Get Input from owners, prospective users, and project managers. A strong user story needs a lot of input to be accurate. Get clear explanations from these groups about what they want to do. Remember, this shouldn’t translate directly into the user story but will provide the necessary information. An owner might say, “I need people to be able to pay with PayPal on my app,” which is very useful but not the user story itself.

Step 2. Decide How User Stories Are Created

This depends on your workflow. In the early stages, user stories are captured on index cards or post-its while planning the overall framework. Later, they are incorporated into project management software. Some team members skip the post-it note stage, while others rely on it – whichever works for you. You might also be wondering how to write a preface.

Step 3. Define, Define, Define

Define the user: With input, you can now define the user. Keep in mind this isn’t always the end user of product features; it can vary depending on the type of user. Create user personas if necessary. Define the action the user is taking, and define the user’s goal in taking this action. Include this key information when crafting your user story to speak to your target audience.

Step 4. Write the Story

Begin writing your user story, it should only be a sentence or two long in order to hold the reader’s attention. It’s tempting to be precise and technical here, but broad language, like mission statements, can be helpful. Make the story clear, and make sure it can be solved or completed, so that you can look back and confirm, “Yes, users can now do this!.” 

Step 5. Divide Into Further Steps

User stories may need multiple steps to reach the end goal, which could require a bit of restructuring depending on the agile framework you are using. Remember, the user story is always the smallest unit in the framework. At this granular level, user stories should take several days to implement.

If it looks like they’ll take significantly longer, that’s a sign to revisit and see if the user experience needs to be broken down further and restructured. If new requirements are added, they’ll also need to be broken down into user stories. While these few sentences are the core of effective user stories, they can also be expanded as development proceeds. Let’s take a closer look at that. You may also be interested in learning what is UX writing.

What are the 3 C’s in User Stories?

Card: The Card phase refers to writing user stories for the development team in a sentence or two. It’s called a card because, user stories were originally written on index cards, and many teams still prefer to do it that way. The Card is the core of its specific software requirement and the starting point for all discussions. It’s also easy to check if your user story is too long – if it can’t fit on an index card that everyone can read, it needs to be shortened.

Conversation: Once the Card sentences have been created, it’s time to hammer out the details. This usually starts as a series of questions between developers, like, “How long is this going to take to implement?” or “How can we incorporate this action?” or “Is this user story essential here?” And so on.

This close examination of the user story will likely yield additional questions to ask project managers and product owners, who should be brought into the conversation as necessary. As the Conversation continues, user stories may be changed, refined, merged, or removed until everyone is on the same page. As user stories are finalized, they’re moved to implementation, a sign that the Conversation is essentially over.

Confirmation: Confirmation is all about acceptance tests, a.k.a acceptance criteria. Once the change has been implemented, and developers report that it’s ready – that the user story has been satisfied – it’s time to test it.

Acceptance tests should be created with the product owner’s input and tie directly back to the user story. In the best-case scenario, it’s a user simply trying to do what the user story indicates and seeing if they can. But acceptance tests can vary and aren’t always made with user stories in mind as they should be. If this creates a problem, it’s time to go back to the Conversation step until acceptance tests and user stories are properly aligned.  If all acceptance tests are completed, the user story is delighted. Now it’s time to either move on to the next step in product development or release the feature.

A 4th C?: Interestingly, some argue that there’s an essential 4th C: Context. In this case, the user story is viewed alongside the other user stories in the project’s greater framework. Here, developers ask if the user story complements other user stories smoothly or if there are gaps – things that the user needs to do or understand that have been missed between user stories.

Ideally, this is spotted during the Conversation phase, but that doesn’t always happen. Some development teams may want a final review of how the completed user story fits into the greater whole and if any further work needs to be done.

What is a Good Format for a User Story?

Let’s go over two formatting techniques that are very helpful when creating user story sentences. The first is very simple: “Who, What, and Why?” In a sentence template, that can be described like this:

As a [Who the user is], I want to [What the user Wants] (so that [Why the user wants it]).

This template may also be framed as: “As a [role], I want to [action], (so that [benefit]),” for simplified terminology. Following this basic format is enough to create the majority of user stories. It’s typically all you need and can help save a lot of time when used for each user story.

Sometimes, however, user stories are harder to define in more complex projects. In this case, a second user story template technique may be useful. It’s called INVEST, an acronym that stands for:

• Independent: Stories should be entirely independent of each other, and stories should be able to be worked on out of sequence as a result.
• Negotiable: Stories should be designed to be altered during the Conversation part of the process.
• Valuable: The user story should demonstrate clear value for the project. If it can’t, it may be a waste of resources.
• Estimable: A user story must be measured in value and prioritization to help decide what to work on in order of importance.
• Small: User stories must be the smallest unit of functionality and should otherwise be broken down further.
• Testable: The user story must be stated in a testable way during the Confirmation process.

FAQs About How to Write User Stories

You may also be interested in our guide on how to write a game review.