Example User Story

[Marcelo Chaplin]

SummaryA user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.

A key component of agile software development is putting people first, and a user story puts end users at the center of the conversation. These stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building, what they're building, and what value it creates.

The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.

User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. These larger structures ensure that the day-to-day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.

For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.

Another common step in this meeting is to score the stories based on their complexity or time to completion. Teams use t-shirt sizes, the Fibonacci sequence, or planning poker to make proper estimations. A story should be sized to complete in one sprint, so as the team specs each story, they make sure to break up stories that will go over that completion horizon.

This structure is not required, but it is helpful for defining done. When that persona can capture their desired value, then the story is complete. We encourage teams to define their own structure, and then to stick to it.

User stories describe the why and the what behind the day-to-day work of development team members, often expressed as persona + need + purpose. Understanding their role as the source of truth for what your team is delivering, but also why, is key to a smooth process.

User stories help shift the focus from writing about requirements to talking about them. Every agile user story includes a written sentence or two to describe a product backlog item from a user perspective. And more importantly, each user story sparks future conversations about the functionality the user story represents. Read on to discover more about user stories and the user story template, including user story examples.

A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories typically follow a simple template:

Historically user stories were deliberately kept informal, written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. Their impermanence made it easy to tear them up, throw them away, and replace them with new stories as more was learned about the product being developed.

Today, user stories might just as easily be stored in a Jira issue or Trello board. Don't let the fact that a user story exists in a tool make you any less willing to discard stories when they are no longer needed!

One of the best ways to learn how to write a user story in agile is to see examples. Below is an example user story or two. These are a few real examples of user stories that describe the desired functionality in an early version of the Scrum Alliance website.

Note that you don't see any user story, "As a product owner, I want a list of certification courses so that..." The product owner is an essential stakeholder, but is not the end user/customer. When creating user stories, it's best to be as specific as possible about the type of user.

User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.

Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.

Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two example user stories:

Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.

User stories in Agile describe the value a user wants from a product without dictating how to create this value. User stories help your team understand what needs to be built, why users need it, and for whom.

User stories can even address highly specialistic situations. For example, loan management is a critical aspect of banking systems. Here are examples of user stories that address such a specific context:

User stories often go hand-in-hand with acceptance criteria. Acceptance criteria explain the specific requirements a user story should meet before you can mark it as complete. Here are several examples of such pairs.

The true purpose of all these examples is to inspire you on a journey from imitation to innovation in crafting your unique user stories. The nature of your product, the specifics of your user base, and the challenges and opportunities your project presents will require a tailored approach. Use these examples as a starting point into exploring uncharted user story territory.

In the agile environment, Product Owners, along with UX designers, tend to write user stories on index cards to be passed around the design team and spark conversation. We might also write them up digitally, using Office or Google Docs to be included in the Scrum backlog.

The fact they are written in simple language and devoid of all technical jargon means the design team feels less restricted by technicalities. They have more opportunity to be creative with their feature design ideas. Read on for some great user story examples!

User stories are brilliant at helping teams prioritize which features to build first. When used as backlog items, they make it easier to organize and divide tasks or feature requirements into sprints. This is crucial for efficient user story writing and user story agile practices.

User stories give agile teams concrete criteria to test against. Each story should have a clear, demonstrable result, ensuring that the user story meets the desired outcome. This helps teams measure performance and outcomes more effectively during each sprint.

User stories help identify the value that certain features will offer users. Agile teams can focus on the most important and immediate features needed upfront, leading to more efficient and profitable work for clients and stakeholders, while also benefiting the user.

The way agile teams write user stories often varies across different organizations and teams. To successfully write user stories, you should always take the following elements into account to provide a comprehensive picture for your team of what exactly is needed at each stage of the product development:

With these three elements, you can write up a brief user story regarding the feature (product requirement) your persona needs and why they need it. We normally write the user story with the following structure:

But what about when you need to write more than one user story, for example? After all, your app or website will have multiple features and your user stories will be short. How do you categorize them into sub-features? The answer is by writing epic stories.

When it comes to the user story writing technique, there are just three basic requirements you need to keep in mind before getting started. Or perhaps you want to sell the idea to other stakeholders.They are the 3 Cs:

The user story should offer value, both to the team and to your user personas. It should give your team a clear idea of the goals of a feature they have to design and develop. And for the user, it means a product that consistently meets their needs.

It should be possible to estimate the amount of work needed for a feature proposed in a user story. This will help you assign the relevant scrum points to the backlog task and manage time effectively.

A user story should be short and memorable. Just two lines about what that user wants to achieve with a specific feature of your product. If it is an overall description of your app or category of features, then write an epic and break it down into sub-stories.

Like with most things in the development process, your user stories should be easily testable with clear deductible metrics for key performance indicators. This is usually where the acceptance criteria come into play.

There are many useful digital templates out there that can also be printed off or used in Jira or another kanban system. But the great thing is that templates can also have many other fields that can be useful, such as scrum points and an area to write your acceptance criteria.

The main purpose of acceptance criteria is to outline the conditions that must be met for a user story to be accepted. They help make sure everyone, from users to developers, understands what the finished product should do.

3a8082e126