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?
- How To Write a User Story
- Step 1. Get Input
- Step 2. Decide How User Stories Are Created
- Step 3. Define, Define, Define
- Step 4. Write the Story
- Step 5. Divide Into Further Steps
- What are the 3 C’s in User Stories?
- What is a Good Format for a User Story?
- FAQs About How to Write User Stories
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.
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.
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.
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
How Do You Write a User Story in Agile?
User stories are a natural part of Agile methodology frameworks, including popular development frameworks like Scrum and Kanban. That means you don’t have to try to write a user story in Agile: They’re already a core part of the framework. Just make sure you include them when adding a new feature or project.
What is the Difference Between a User Story and a Requirement?
They may look like the same thing at a glance, but they are significantly different. The user story describes goals from the user’s perspective – what the user, based on their own experience, wants to do. On the other hand, a requirement is what the software itself should be able to do – it’s a much more technical description. User stories should inform requirements and go into greater-depth steps for product management.
You may also be interested in our guide on how to write a game review.
Join over 15,000 writers today
Get a FREE book of writing prompts and learn how to make more money from your writing.