Good user stories don't just help with customer satisfaction, they also help improve employee-customer relationships.
Agile development culture advocates giving importance to individuals over processes and tools, and user stories lend a human aspect to the feature backlog. A user story isn't just about what you're building—it should also help you understand why you're building it. This understanding will also improve The process of how you build the same feature.
A typical user story might look like this:
"As a <user role>, I want to <feature> so that I can <receive benefit>."
"I'm Brad, a user of the online flight booking portal, and I want to know if my ticket is booked so I don't have to try booking again."
Knowing that you're helping a human solve a tangible problem with the feature you're building is more motivating than just developing a list of features your manager assigned to you. Good user stories don't just help with customer satisfaction—they also help improve employee-customer relationships.
Why write user stories?
User stories help you find clarity. For example, if your task is to create a "Login page," you might simply visualize a screen where the user enters their username and password to access the platform or service. However, when you imagine a human in front of the login page, you might realize you'll need an error message if the credentials are wrong and a password recovery mechanism in case they forget their password. User stories help you define how your user will perceive and engage with each feature.
User stories help you define how your user will perceive and engage with each feature.
Components of an agile user story
A user story usually has three components:
Title:
The title should be concise and explicit. Something like "Add signup form on the homepage" is a good example while "Make agreed upon changes" is not.
Description:
The description is the heart of the user story, and is often written using a template. For example, "As a customer of an online cab booking service, I want an online payment to be an option so I don't have to carry cash with me all the time."
Acceptance Criteria:
This is used to define when a user story can be deemed complete. Writing good acceptance criteria is an effective way of exploring all the details of a user story and defining its scope.
Example
As a university student
I want to know my fee for the semester
so that I can pay the amount.
Acceptance Criteria for this story may be:
1. The fee is displayed.
2. The fee is calculated.
3. The fee for the upcoming semester is displayed.
4. The fee is not displayed for an invalid student ID.
Acceptance criteria are defined before development begins. A good practice is to write them in clear, simple language, which can be translated into manual or automated test cases.
User stories in Agile Software Development
A user story is the smallest chunk of a product feature that you can explain independently. It shouldn't contain technical details, should be captured in a sentence or two, and should prompt a discussion during which the details are nailed down.
User stories should be written in plain English without technical jargon so non-technical members of the team to contribute to the discussion. Developers work with many technologies and often use acronyms and jargon that might not be understood, even within the same team. With user stories, anyone can contribute by simply putting themselves in the shoes of a potential user.
The Product owner who has a clear vision for the product along with a sound understanding of its user base—should write the first set of user stories. As the team starts brainstorming, all stakeholders can contribute user stories, including the development team.
With user stories, anyone can contribute by simply putting themselves in the shoes of a potential user.
User story templates and formulas
There are helpful templates which can be used for writing user stories. Some examples of these templates are:
INVEST
- I
Independent
The goal a user story aims to achieve should be independent of other product goals.
- N
Negotiable
The details of a user story should be up for negotiation. For example, the first iteration of a login page can go live with just an error message. A password recovery mechanism can be added later.
- V
Valuable
A good user story should add value to the end user.
- E
Estimable
It should be possible to estimate the efforts required to complete a user story.
- S
Small
The goal defined should be small enough to fit within one sprint.
- T
Testable
Any feature or enhancement that is the result of a user story should be testable - you should be able to write acceptance criteria before it's implemented.
Role-feature-benefit
This is the most popular template used. It looks like this:
As a <user role>, I want to <feature> so that I can <receive benefit>.
Some teams go a step further and use an actual name to make their user feel more human.
The 3 C’s of a user story
The 3 Cs formula captures the components of a user story.
Card:
Typically a sticky note with a rough one- or two-line description of the user story
Conversation:
A largely verbal conversation about the user story and how it can be explored. This could include anyone remotely involved with the feature
Confirmation:
A tangible output which confirms the conversation's objectives have been achieved.
Given-When-Then
Given (some context or description of the situation) When (some event(s) occur ) Then
(some observable reactions should occur)
It's not unusual for teams to fall into the rote application of these templates. A template or formula can be a useful reminder to keep the conversation focused on the user. Remember, normal phrasing can be just as effective in communicating the essence of a user story—the discussion around the user story contributes more to its implementation than the initial two lines written on the card.
How to write effective user stories?
Writing agile user stories may appear easy enough, but writing effective ones can prove to be challenging. Incorrect user stories lead to wrong interpretations and implementations, which can cause frustration within a team. Here are some tips for writing user stories:
You can't write user stories from a requirement document.
Epics are higher-level user stories, whose work spans across multiple sprints. You can use Epics to group similar user stories working toward a common goal.
Think ahead. While acceptance criteria can be good enough for short term success in the software life cycle, product decisions should be driven by user feedback. Learn how your targeted users perceive and interact with the feature to understand how to improve it.
Understand your user personas. A user persona is the profile of your target user, created to help empathize with and understand the people you're developing the product for. It could be as specific as "Girls between the ages of 13 to 20" (for a teen magazine) or as general as "Men" (for a razor). If you don't know your users, you can't solve their problems.
The level of detail needed for a user story changes over time. You can more easily understand the user story for the next iteration of a feature than the one planned for the upcoming release. The context and the lessons learned from one iteration of a user story will influence the next one.
User stories are not tasks. A user story might require 10 tasks to complete, and they have different purposes. Tasks are concerned with implementation while user stories provide definition.
User stories can help you empathize with a user and fully understand the problem you're trying to solve. When used effectively, a user story is a small tool which yields enormous impact on shaping your end product. When something is well planned from the beginning, it's already halfway done. Similarly, if you get your user stories right, you can rest assured knowing you would spot the red flags on your product road map early on.
Do you think you're ready to write your own user stories?
Start sprinting with us now
