User Stories

You definitely know what stories are. We have grown up listening and telling them. Storytelling is a kind of art that has a significant contribution to human history.

What are the stories in Agile project management? What are user stories about? In order to understand why and how we use them in Agile development, it’s worth having a closer look at user stories.

These stories are not part of any particular Agile framework. However, they represent a practice applied by many teams as a format for expressing product requirements. Stories in Agile frameworks are simple and versatile, that is why they have become the most popular form of product backlog elements.
What are the key parts of a user story? How do you write a user story example? What makes a good user story? As always, we have many similar questions. Let’s study their phenomenon right now!

What Is a User Story in Agile?

An Agile user story is a simple, plain-language, and short description of a feature narrated from the perspective of the person who wants new capabilities of the system (usually a customer or user).

User story as a reliable Agile tool

User stories help to implement specific business requirements and provide value. The story is aimed to capture a single feature, use case, enhancement, particular role, or scenario.

We typically face user stories written in the following format:

As a ______, I need to ______ so that ______.

User stories can be even created on cards or sticky notes and arranged on walls to encourage discussion and planning activities.

What Is the Goal of the User Story?

The key goal of any user story is to write down how a certain project will deliver value back to the end-user. Ideally, the development team should collaborate with stakeholders and business owners to clarify the details as the code gets developed.

A Couple of Words About the History of User Stories

The roots of the user stories concept originate with Extreme Programming. The first description related to stories (written in 1998) compared them to use cases. They were described as one of the “game pieces” used in the “planning game”.

With the growth of XP and Scrum‘s popularity, a product backlog made up of user stories is the most commonly known approach to Agile requirements definition.

Over the years, stories were described more thoroughly, which led to the emergence of a more sophisticated account of user stories.

Characteristics of a Good User Story

A winning user story should be:

• Small. Big Agile stories are difficult to estimate, and they are less negotiable.
• Independent. A well-written story should be independent of other stories to allow you freely move it around the backlog when priorities change.
• Valuable. Efficient user stories provide customers with value. There is no sense to put effort into the story without value.
• Negotiable. All the details of a story should be created in collaboration between customers and the team. Negotiating the scope is a must.
• Testable. If your customers and the whole team cannot specify how to verify you have implemented what they want, you haven’t added enough clarity about this user story.
• Estimable. Without the ability to estimate a story, you will not understand the scope.

Who Usually Writes Scrum User Stories?

User stories in the Agile environment can literally be written by anyone. This is not a direct and obvious responsibility of the Product Owner, although he/she makes sure that a product backlog of user stories exists. So, the PO is not the only one who writes stories. It is important to understand that the one who writes a user story is far less important than those who discuss it.

When Do We Write User Stories?

Agile teams write user stories throughout the whole project. It is a good practice to run a special story-writing workshop shortly after the project begins.

What Is the Principle of Work on User Stories?

After completing a story, you have to integrate it into your current Agile workflow. During a sprint planning meeting, the Agile team defines what user stories they will take to the sprint. Then all requirements and functionality that every user story implies are discussed by the entire team. The agreed requirements are added to the story. Working on the story takes both creative and technical skills and approaches.

Another crucial part of the meeting is scoring. It is based on the user stories’ complexity or time to completion. Fibonacci sequence, Planning Poker, and t-shirt sizes are the most-used practices for arranging qualitative estimations.

User Stories and Use Cases: How to Define the Difference Between these Tools Used in Product Development

Both user stories and use cases describe how a user might interact with a product to find the solution for a particular problem. However, they are not interchangeable.

In fact, use cases document both goals of users and the functional requirements of the system. They are aimed to capture much more detail than a story about the process a user goes through to reach the outcome from interacting with a product.

• User stories are written in the form of a brief statement describing only the user’s end goal
• Use cases often describe several additional steps that may include preconditions required before the use case begins, the main flow of events describing a user’s path to completing an action with the product, paths’ options a user might take with the product, as well as a visual diagram visualizing the entire workflow.

Stories vs Features vs Requirements

How do they differ?

• A user story is about describing the value a user gets from a certain activity.
• A feature is what a software solution can do.
• Requirements are what the software solution must do as well as how it does that.

Usually, requirements define the criteria that software features need to satisfy.

A product backlog can be considered as a replacement for the traditional project’s requirements doc. However, note that the written part of any user story is not complete until the discussions about this story are over.

Why Create User Stories? (Vivid Benefits)

Project requirements tend to change, especially when teams and clients learn more about the system as the project progresses.

Due to focusing on customer-centric conversations, Scrum user stories reduce the time spent on preparing exhaustive documentation. They allow delivering quality software more quickly, and clients surely appreciate it. Implementing the user story approach in Agile development will benefit you in the following way:

• Providing a simple and consistent format. It saves time when capturing and prioritizing requirements
• Expressing business value by delivering a product that customers need.
• Avoiding false completeness and clarity.
• Avoiding too early details that can prevent design options.
• Providing small chunks that encourage negotiation and movement in the backlog.
• Leaving all tech functions to developers and testers.

What Are Common Pitfalls Related to Stories?

• As we’ve mentioned above, a user story is not a use case. They can be compared and contrasted, but they are not equivalent and can not be one-to-one mapped.
• A user story is not a document. It includes all knowledge required to transform one version of the product into another one that looks more valuable.
• This is a mistake when teams where Agile is confined to the development team start from a requirements doc in narrative format and derive stories based on its structure. For example, one story for each section of the document.
• The level of detail corresponding to a user story is not constant. It evolves over time as a function of the planning horizon.
• User stories do not commonly correspond to technical or UI components. Even though it may sometimes be a useful shortcut to talk about.

The Format of User Stories

How to write effective stories? If you do not know where to start, a useful template will help you not confuse the story with writing technical tasks.

A user story template captures the essential elements of a requirement that cover the who, what and why questions.

A sample user story format should contain:

• The Role. It means that the user should be a real human who interacts with the system.
• The Action. It means that the system behavior should be written as an action.
• The Benefits. They should be a real-world result that is non-functional or external to the system.

User Story Examples

What is a user story example?

• As a [customer], I want [shipping functionality] so that [I can faster get the goods I order].
• As a [product manager], I want to [plan the quarter’s activities] so that [I can understand how to distribute the workload of employees].
• As a [user], I want to [get double notifications when the goods arrive] so that [I don’t miss the arrival].
• As a [PM working remotely], I want [to appoint an online meeting with the distributed colleagues] so that [we can optimize the current user stories and discuss them in detail].

With the help of these examples, we can see that:

• The Role is the person or any entity else who will interact with the system to be implemented to reach the goal.
• The Action demonstrates the user’s expectation that will be accomplished by interacting with the system.
• The Benefits are the value behind the interaction with the system.

The Way to Identify User Stories

The best way to identify user stories is to involve stakeholders, preferably using a face-to-face meeting. If we refer to the traditional requirements capturing approaches, we’ll see that this is a role of a system analyst to understand clients’ needs and prepare a detailed requirement specification for the system.

However, the user story approach works differently. The identification of user stories looks like a note-taking process but not as documentation.

To identify user stories, you have to perform the following steps:

• Listen to your users attentively and understand their needs.
• Write down all the needs and requirements you’ve heard as user stories.
• These user stories will become the source of requirements.
• Then add details just-in-time and provide your team with required references throughout the project development process.

How to Add Details to Scrum Stories?

You can add details to user stories in two ways:

• By breaking down a user story into smaller stories.
• By adding conditions of satisfaction.

When you split a large Agile story into multiple user stories, it is logical that detail has been added.

What Is the Lifecycle of a User Story?

Six general states for any user story throughout a project are typically the following ones.

1. Pending

You may generate Scrum user stories based on communication between the members of your Agile team and users. These stories will contain a brief description of users’ needs.

2. To-do state

During the discussion session between all the parties involved, the stories that will be reviewed in the next weeks are determined. They move to a sprint and get a “to-do” state.

3. Discussing

Now it is time for the discussing state when developers communicate with the end-user. They discuss requirements’ confirming and the acceptance criteria.

4. Developing

After clarifying all requirements, the development team starts to design features and implement them.

5. Confirming

When your story is implemented, it’s high time to confirm it with the end-user (who gets access to testing). The confirmation items noted while detailing the story will be the basis for confirmation.

6. Finish

This state means that the features are confirmed and done. This is the end of the user story.

How to Create User Stories

In order to prepare successful user stories, you’d pay attention to the following:

• “Done” definition. The story gets the “Done” status when your client can complete the outlined task.
• Outlining tasks and subtasks. You should define particular steps that have to be completed and decide who is responsible for each step.
• User personas. This should be the answer to the question “for whom”? If you have several end-users, then make several user stories.
• Ordered steps. It is a good idea to prepare a story for each step in a larger process.
• Considering time. Often development teams avoid discussions of time, relying on their estimation systems.
• Considering feedback. Communicate with your users and capture their needs in their words.

What Is the Concept of 3 C’s?

3C’s in writing user stories means a card, conversation, and confirmation.

• Card means that you write sample user stories on cards and use them for estimating, prioritizing, and scheduling.
• Conversation means that you practice conversations and discussions between customers and all involved in order to formulate specific requirements and achieve the clarity needed for implementation.
• Confirmation means that you run acceptance tests to confirm that the stories software fits the acceptance criteria or not.

Final Tips on How to Create and Manage User Stories Effectively

If you know how to properly apply a user story in your project, you will produce reliable and high-quality software and win the trust of your clients. Follow these additional recommendations for preparing a successful user story:

• Try to describe your stories in a brief form.
• When writing a user story, think from your client’s point of view.
• Define confirmation items before the development process starts.
• Estimate the story before its delivery to understand that your team’s workload is under control.
• Remember that requirements are found with the end-users, not by the development team.
• Optimize communication to understand what the end-user wants.

Summary

By considering the type of user, what they strive to accomplish, and why they want to accomplish certain tasks, user stories bring in clarity to Agile projects.
By understanding how to write effective and trustful user stories, you will be able to communicate and optimize the work that needs to be done.
We hope that now you know how to write user stories faster and with high quality using the tips and info described above. So, make your user story problems go away, become an effective story writer, and amaze your customers!