What Is a User Story?
A user story is a short, simple explanation of a software feature written from the perspective of the person who desires a new capability. The purpose of a user story is to articulate 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.
They can be recorded on index cards, post it notes, or recently with the influx of SaaS, in a product management tool.
A User story can be written by a variety of stakeholders such as clients, users, managers, or development team members.
What Is a User Story in Agile?
In the agile framework, a user story is the smallest unit of work. It can be understood as an end goal, not a feature, expressed from the user’s perspective.
The purpose of a user story in agile is 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, but rather, they can be internal customers or colleagues with the organization.
To put it plainly, user stories are a few sentences in simple language that outline the desired outcome. There isn’t much detail, but rather, requirements are added later once agreed upon by the team.
A Kanban or a scrum is a great way to lay out all potential user stories. In Kanban, teams pull user stories into their backlog and run them through their workflow. In scrum, user stories are added to sprints and “burned down” over the duration of 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 and multiple epics is what an initiative is composed of.
What Are the 3 C’s in User Stories?
An initial set of user stories is defined as part of the discovery process and additional user stories are continuously added by the team on an as needed basis during delivery. Defining user stories is a convenient way of capturing requirements at a high level of detail while focusing on user goals, which is why they can be so successful in determining value for your users.
With that being said, a good user story consists of three elements, commonly referred to as the 3 C’s:
Although this can be taken literally, the idea behind the first C, card, essentially means that the optimal size of a user story can fit on an actual note card.
The card should not contain all information about the requirement, but instead, just enough to be used in planning to identify the requirement 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 needs to be on gathering user stories for each user type to create a set of the most representative user stories possible.
Ideally, they should be written by the users of the product, but it’s okay if they’re written by other stakeholders or the product owner.
You can gather user stories by any variety of user research methods such as interviews, questionnaires, observations, amongst others.
Before user stories are placed in the sprint, the product owner should talk to customers about their user stories for elaboration and validation.
These conversations are necessary as a user story may be difficult to interpret and background knowledge could be key for implementation.
These conversations allow product owners to inform stakeholders of what’s going on and allow everyone to digest information accordingly.
In context, conversations can also include electronic communications through email, internal chat, or any other online connection tool your cross functional team may use.
The final C of a user story is the acceptance criteria used to confirm that the user story has been implemented correctly and is successfully delivered.
Acceptance criteria must be defined before development begins to determine when each user story is finished and working as intended.
These criteria can be used to demonstrate a user story’s boundaries and are often thought up during conversations between the product owner, product manager, and users.
Defining this criteria before user stories are placed in a sprint is generally the best practice.
How to Write Good User Stories?
Put Users First
As we’ve discussed and you can probably guess by now, a user story describes how a customer or user employs the product from the user’s perspective.
If you do not know who the users are and why they want this product, then they shouldn’t write a user story.
Do adequate research first otherwise you will run the risk of 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 that are based on first-hand knowledge of the target group. They usually include a name and a picture, relevant characteristics, behaviors, and attitudes, and an overall goal.
The goal can be understood as the benefit a specific persona wants to achieve.
The question that needs to be asked is “what functionality should my product provide to meet the goals of the personas?”
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.
It’s vital that the product owner and the team discuss these stories together. This will allow you to capture the necessary information, reduce cost, and speed up delivery.
You can even take this approach a step further and write stories together as part of the backlog grooming process. This leverages creativity and knowledge of the team leading to better stories.
Make sure the stories are simple and concise
The simpler the better when it comes to user stories.
Avoid confusing and overly fluffy terms. Don’t forget to use an active voice.
Focus on the important parts.
Leave out everything else.
Roman Pichler created a template based off of Rachel Davies’ popular template.
I want <what?>
So that <why?>
Start with Epics
An epic, as previously mentioned, is typically broken into several user stories over time making sure to leverage user feedback in early prototypes. They’re a placeholder and headline for more detailed stories essentially. Think of it as the scope.
Starting with epics lets you sketch the functionality without committing to anything specific.
It specifically comes in handy when describing new products and features: it allows a product manager to capture the rough outline whilst buying time to learn more about how to address the needs of users.
It also saves time because instead of having multiple disjointed, detailed stories in the product backlog, you have an epic organizing them accordingly.
Refine your stories until they’re where they need to be
Continue to break your epics into smaller and more detailed stories until they are clear, feasible, and testable.
All developers should have a shared understanding of the story’s meaning whilst not being too big. On top of this, there has to be an effective way to determine if the story is done.
Include Acceptance Criteria
As you are breaking down your epics into smaller stories, it’s imperative you have acceptance criteria.
It will complement the narrative allowing you to describe the conditions that have to be fulfilled so the story is done.
The criteria will make the story testable, enrich it, and that it can be demoed and released to users and stakeholders.
A good rule of thumb is to have 5 acceptance criteria for detailed stories.
Use Paper Cards
User stories initially were born from extreme programming and literature around it talking about story cards rather than user stories.
This is because the stories were captured 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, and lastly, cards can be grouped easily 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. Whether it’s in Chisel, or physically on walls; having them visible readily fosters collaboration, creates transparency, and makes it obvious when there are too many stories too quickly.
Don’t rely solely on stories
Creating a great user experience is more than just having well-crafted user stories.
They’re helpful in capturing product functionality, but make sure to compliment them with other techniques like workflow diagrams, storyboards, mockups, or sketches.
Beyond this, they’re not good at capturing technical requirements. If you need to communicate an architectural element, then write a technical story.
If you want to create a product that is likely to be reused, user stories are great.
If you’re just trying to quickly build a prototype, then writing stories may not be necessary.
Remember– user stories are about enabling you to move fast and develop as quickly as possible.
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 they both describe the goal, but they serve different purposes. The differences are as follows:
Degree Of Detail
User stories are normally, and purposefully, more vague. They provide a simplified description of what a feature should help a user do, leaving it open to more interpretation.
Use cases cover more ground by showing how the user ought to interact with the system and how the system should reciprocate. They go into more detail about the individual steps in a feature’s process.
User stories are generally able to fit into one spring as 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 as they give an overview of a larger 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 exactly the user wants to achieve that can be written on a simple index card. This makes them quick and easy to create.
Use cases, on the other hand, can take more time to put together as they detail out each step and are more often than not, represented in a diagram.
This makes use cases potentially more helpful in a practical sense for identifying friction points in the process, however, this can also be done by using a combination of user stories and flows, which basically map out different screens a user goes through in the process.
When to Use User Stories or Use Cases?
When faced with the situation of which to use, it all depends on your team, its size, and the product you’re working on.
The rule of thumb for deciding is having a discussion with all stakeholders involved in the product to hash out the pros and cons of each type of mapping. At Chisel, we always advocate for 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.
When combined, they keep the plain language tone of user stories, but go into extra detail about system functionalities to satisfy user goals.
Some experts even recommend starting with use cases first and then moving on to user stories at later iterations once the basis is sound.
To break it down, you’d be using use cases to create the fundamental features of the product and then using user stories when adding the extra features to speed up further development.