What Is a User Story?
A user story is a short, simple explanation of a software feature written by someone who desires a new capability.
A user story articulates how a software feature will provide value to the customer.
A user story describes the type of user, what they want, and why.
It helps create a simplified description of a requirement.
In a product management tool like Chisel, you can record user stories on index cards, post-it notes, or with the influx of SaaS.
What Is an Agile User Story?
In the agile framework, a user story is the smallest unit of work.
It is an end goal, not a feature, expressed from the user’s perspective.
An agile user story aims to articulate how a piece of work will deliver a particular value back to the customer.
“Customers,” in this context, don’t have to be current users in the traditional sense.
Instead, they can be internal customers or colleagues within the organization.
In other words, user stories are a few sentences in simple language that outline the desired outcome.
There isn’t much detail, but you add the team’s requirements later once agreed.
In kanban, teams pull user stories into their backlog and run them through their workflow.
On the other hand, in the scrum, user stories are added to sprints and “burned down” throughout a sprint.
Think of user stories as the building blocks of larger agile frameworks like epics and initiatives.
Epics are large work items broken down into stories, while multiple epics are composed of an initiative.
What Are the 3C’s in User Stories?
An initial set of user stories is part of the discovery process.
The team constantly adds new user stories during agile delivery.
Defining user stories is a convenient way to capture detailed requirements while focusing on user goals.
That’s why they can successfully determine the value for your users.
A good user story consists of three elements called agile three C’s.
Although you can take this literally, the idea behind the first C – card refers to the user story’s optimal size that can fit on a notecard.
The card should not contain all information about the requirement.
Instead, it must have enough information to plan, identify the need, and remind the team of the overall story.
This is the format they should follow:
“As a [particular user], I want to [perform this action] so that [I can achieve this goal].”
The focus should be on gathering user stories for each user type.
It helps create a set of the most representative user stories possible.
Ideally, product users should write user stories.
However, it’s okay if other stakeholders or the product owner write them.
You can gather user stories through various user research methods such as interviews, questionnaires, observations, and others.
These conversations are necessary as a user story may be difficult to interpret.
Plus, background knowledge could be essential for implementation.
These conversations allow product owners to inform stakeholders of what’s going on.
It also allows everyone to digest information accordingly.
Conversations can include email, internal chat, or any online tool for your cross-functional team.
The final C of a user story stands for the acceptance criteria.
It confirms that the user story has been implemented correctly and is successfully delivered.
It would be best if you defined acceptance criteria before development begins.
It helps determine when each user story is finished and working as intended.
These criteria demonstrate a user story’s boundaries.
They are a common point of discussion during conversations between the product owner, product manager, and users.
The best practice is to define this criterion before placing user stories in a sprint.
What Is a Good User Story?
INVEST is the acronym you can use to know if you are on track to writing good user stories.
Every agile user story must be independent and should stand on its own.
It helps in prioritizing, also called user story priority.
Also, you can move them in the product backlog if the agile user story is independent.
When implementing the agile user story format, there’s a collaboration between teams and customers.
This is where the negotiation comes in.
You will have to decide on what to implement and what to skip.
When writing user stories, remember that they must be valuable to the customers.
You must be able to estimate an agile user story.
If a user story is not estimable, then the scope of that story is not well understood.
When estimating agile user stories, you can easily distinguish between high and low-effort stories.
When writing user stories, know that it must take less effort (days or a few weeks) to implement it.
Any agile user story that is high in effort is difficult to estimate and negotiate.
One of the best indicators of writing better user stories is testability.
When a customer cannot tell if you have implemented their story, the entire team’s effort may be in vain.
To avoid this, write the acceptance criteria before implementing the agile user story.
How To Write Good User Stories?
You may know how to write user stories.
But have you ever wondered how to write good user stories?
If yes, we will consider how to do so efficiently in no time.
Put Users First
As discussed, a user story describes how a customer employs the product from their perspective.
You shouldn’t write a user story if you do not know who the users are and why they want this product.
Do adequate user research first; otherwise, you will risk speculating.
Discover the Right Stories With Personas
Personas are a great technique to capture your insights about the users and customers.
Essentially, they are fictional characters based on first-hand knowledge of the target group.
They usually include a name, picture, relevant characteristics, behaviors, attitudes, and overall goal.
You can understand the goal as a benefit a persona wants to achieve.
You need to ask, “What functionality should my product provide to meet the personas’ goals?“
Collaborate When Creating Stories
User stories are supposed to be lightweight to allow you to move fast.
Think of them as a collaboration tool more than a specification.
The product owner and the team must discuss these stories together.
It will allow you to capture the necessary information, reduce cost, and speed up delivery.
You can even take this approach and write stories together as part of the backlog grooming process.
That leverages the creativity and knowledge of the team leading to better stories.
Make Sure the Stories Are Simple and Concise
It is ‘the simpler, the better‘ regarding user stories.
Avoid confusing and overly fluffy terms.
Don’t forget to use an active voice.
Focus on the essential parts and leave out everything else.
Roman Pichler created a template based on Rachel Davies’ popular template.
I want <what?>
So that <why?>
Start With Epics
They’re a placeholder and headline for more detailed stories.
Think of it as the scope.
Starting with epics allows you to sketch the functionality without committing to anything specific.
It comes in handy when describing new products and features.
Using it, product managers can capture the rough outline while buying time to learn how to address users’ needs.
Suppose you have multiple disjointed, detailed stories in the product backlog.
In that case, you can have an epic organizing them.
Thus, epics make your whole process time-efficient.
Refine Your Stories Until They’re Where They Need To Be
Continue to break your epics into smaller, more detailed stories until they are clear, feasible, and testable.
All developers should have a shared understanding of the story’s meaning while not being too big.
On top of this, there has to be an effective way to determine if the story is complete.
Include Acceptance Criteria
As you break down your epics into smaller stories, you must have acceptance criteria.
It will complement the narrative allowing you to describe the conditions you must fulfill to complete the story.
The criteria will make the story testable and enrich it.
You can demo and release it to users and stakeholders.
A good rule of thumb is five acceptance criteria for detailed stories.
Use Paper Cards
Initially, user stories were born from extreme programming
Moreover, the literature around it talked about story cards rather than user stories.
It is because teams captured the stories on paper cards.
There are three benefits to this:
- Paper cards are cheap and easy to use.
- It leads to collaboration as everyone can take a card and jot down an idea.
- You can group the cards quickly and cleanly visually.
- If you are in the office, it can have a tangible benefit.
Make Sure Stories Are Visible and Accessible
The central role of stories is to communicate information.
Therefore, make them visible.
Having visibility fosters collaboration and transparency, whether in Chisel or physically on walls.
It makes it obvious when there are too many stories.
Don’t Rely Solely on Stories.
Creating a great user experience is more than just having well-crafted user stories.
They capture product functionality but compliment them with other techniques.
These techniques include workflow diagrams, storyboards, mockups, or sketches.
Beyond this, they’re not good at capturing technical requirements.
If you need to communicate an architectural element, write a technical story.
User stories are great if you want to create a product that is likely to be reused.
Writing stories may not be necessary if you’re trying to build a prototype quickly.
Remember – user stories enable you to move fast and develop as quickly as possible.
How To Gather User Stories?
While writing user stories, don’t forget to note down the methods you can use to gather them.
Following are some ways you can collect user stories:
Ask relevant questions to a diverse audience will help you know what new features you need to add.
Or, if the product is new, then asking the potential customers open-ended questions will be beneficial.
Have an eye for details and observe how customers use the product.
Such observation can also help you write user stories.
By Conducting Surveys
Survey with questionnaires related to the user stories.
Share it online or in hard copy to derive results.
Show your agile user story ideas to the teams.
Then, open the platform for discussion through PowerPoint presentations.
Another way of gathering and writing user stories is by brainstorming ideas.
A session with participants discusses as many user stories as possible.
It would be best not to assess the ideas while in the workshop.
This way, having a pool of user stories in place becomes more effortless.
User Story vs. Use Case
Is a user story the same thing as a use case?
Although they share similarities, user stories and use cases are not interchangeable.
However, they both can identify users and describe the goal, but they serve different purposes.
The differences are as follows:
Degree of Detail
User stories usually are, and purposefully, vaguer.
They provide a simple description of what a feature should help a user do.
Thus, it leaves it open to interpretation.
Use cases cover more ground by showing how the user should interact with the system.
They also cover how the system should reciprocate.
They go into more detail about the individual steps in a feature-driven development.
User stories can generally fit into one sprint.
They contain features or details small enough to be completed as quickly as possible.
A team can even get through multiple user stories in one sprint.
Use cases tend to cover several sprints, providing an overview of a more extensive functionality.
They generally list out each step of a feature’s process.
The user story is just a line or two of a statement about what the user wants to achieve.
You can write that on a simple index card, making them quick and easy to create.
On the other hand, use cases can take more time to put together.
That’s because they detail each step and represent it in a diagram.
This makes use cases potentially more helpful in a practical sense for identifying friction points in the process.
However, you can also do this by combining user stories and flows.
It helps map out different screens a user goes through in the process.
When To Use User Stories or Use Cases?
When faced with which to use – user stories or use cases, it all depends on your team, its size, and your product.
The rule of thumb to decide is to discuss with all stakeholders in the product to hash out the pros-cons analysis of each mapping.
At Chisel, we always advocate keeping things agile, but every scenario is different.
If all else fails, using them together is usually your best bet if done strategically, rather than one or the other.
Combined, they keep the plain language tone of user stories.
However, it can go into extra detail about system functionalities to satisfy user goals.
Some experts even recommend starting with use cases first.
Later, you can move on to user stories at later iterations once the foundation is sound.
To break it down, you’d be using use cases to create the fundamental features of the product.
And then, you will use user stories when adding the extra features to speed up further development.
What Are the Good User Story Examples?
Let’s have a look at good user story examples. This way, you will also understand an agile user story format.
- As an (audience), I want (a review button) so that (I can see how other customers rate the product before purchasing).
- As a (regular customer/buyer), I want (a notification option once the item is shipped) so that (I can make the necessary arrangements to pick it up).
Since you can write an agile user story at varying degrees of detail, sometimes an extensive functionality fits into one user story.
This is called the epic.
- For example, As a manager, I want to get an information-based report to know when the teams need help regarding resources.
You can divide this epic into various or even hundreds of user stories, such as:
- As a manager, I want a datasheet so that I can verify which teams are working on what tasks
- As a manager, I want a daily report to avoid piling up until the end of the month.
You are familiar with an agile user story and how to write good user stories.
Learn about the anatomy of a user story, and you are on the way to writing better user stories.