What Is a User Story?
According to one of the initiator of the Agile movement Alistair Cockburn, “A story card is a promise for a conversation.” Specifically, it is a conversation with your customer that results in a description of a software function from their perspective. This is the basis of a user story — an essential part of the Agile and Lean software development lifecycle. Themes, initiatives, epics, and stories are all building blocks, from large to small, that help organize the functionality necessary to build a user-centric software solution. The terms may seem familiar from a literature angle, and rightfully so. A user story is a simple narrative, while related stories make up an epic. Here’s how these terms work together:
Themes: An ambitious purpose or high-level goal.
Initiative: A collection of epics that that will help reach the main goal.
Epics: A high-level business need or large user story. These are difficult to implement in a single iteration, so they are broken down into smaller stories. An entire epic is usually included in a single release.
User Stories: Short requirements or user scenarios that provide some value and are written from the user’s perspective. Each story is bounded by a sprint or iteration.
An example of this can be seen here:
The theme (far left) is the high-level business goal that is made up of associated initiatives, epics that support those initiatives, and stories (far right) that describe granular requirements.
A software development organization may have the lofty goal of modernizing their solution. To accomplish this task, they must provide an unforgettable user experience. For example, that user experience must provide a modern web interface, perform quickly, and work on a variety of user devices. In this scenario, each of these epics will be broken down into specific user stories.
What Is an Epic User Story?
An epic is a high-level business need or large user story. Epics are too complex to implement in a single sprint or iteration, so they are broken down into several smaller user stories. The benefit of epics is the ability to develop and collaborate on larger ideas prior to creating numerous user stories. The epic can be maintained as the original idea, creating a future reference point.
What Is the Purpose of a User Story?
A user story is intended to aid in the development of a software solution. Unfortunately, it is not uncommon to develop a software solution that simply doesn’t appeal to the intended customer base. User stories are meant to mitigate this risk by providing a clear and thorough understanding of the end-users’ requirements that ensures the software feature(s) meet expectations.
How Do Companies Use User Stories?
User stories are one of the primary artifacts used in Agile development. They are created to describe functional and non-functional features and requirements and make up a prioritized list of functionality intended for development. This list is called the product backlog.
User stories become part of a user story map, a method used to order user stories along a horizontal and vertical axis in order to represent varying levels of usability. The horizontal axis walks through the activities that explain how the user interacts with the system to perform a function. The vertical axis represents increasing levels of complexity. The first row is a fundamental depiction of the function. The next row adds a little more functionality, and so on. Each user story is assigned a story point or a theoretical estimate of effort or difficulty that it will take to develop the functionality. Many organizations use automated story mapping tools. The most popular tools are Jira, Rally by CA, StoriesOnBoard, and FeatureMap.
User Story Map Template
You can also use this template to build your own story map. You can complete the template using Microsoft Word or recreate it using Post-it notes that you stick on a wall. Adjust the number of boxed based on your organization’s development needs.
Download Template in Word
Try Smartsheet Template
What are the Characteristics of a User Story?
Regardless of the Agile framework used, Extreme Programming (XP), Kanban, DAD (Disciplined Agile Delivery), AMDD, or Scrum, user stories are the same. The user story describes the type of user: the persona, the feature they want, and the benefit they expect to experience from the feature. A strong user story is written following the role-feature-reason (RGB) structure:
As a <role>, I want <feature>, so that <reason/benefit>.
The user story should have the following qualities:
Be complete enough to demonstrate user value.
Be user-centric.
Start with an epic.
Be short, simple, and clear.
Contain supporting files and documentation if necessary.
Be comprehensive enough to demonstrate value, but simple enough to develop in a single iteration.
Be written based on the input of all stakeholders.
Be flexible and negotiable without impacting other stories or features.
Be easy to test.
Include acceptance criteria (conditions of satisfaction) for testers.
You may hear the terms user stories and system requirements used interchangeably. Traditionally, Waterfall development uses system requirements to define how a software solution should function. They go into extensive detail that includes risks, scope, and other development-specific guidelines. User stories, on the other hand, are simple, promote discussion, and support the Agile development methodology, which embraces collaboration and change.
As mentioned earlier, user stories should be simple yet complete. For example, a good user story might read like this:
As a bank customer, I want to be able to deposit a check online, so that I don’t have to visit the bank.
Here is an example of a user story that is too detailed:
As a bank customer, I want to be able to deposit a check online, view and print historical deposit reports, so I don’t have to visit the bank.
What Is a Story Point?
Each user story is assigned associated a story point, a measurement of the effort or difficulty required to develop and implement it. Teams may use single digit numbers (1, 2, 3), multiple digits (100, 200, 300), or any other number format they choose. The ratio is the important factor. For example, a story that is assigned 200 story points will require twice as much effort as one assigned 100 story points.
What is User Acceptance Criteria?
Acceptance criteria, also known as conditions of satisfaction, ensures the software solution satisfies the needs of the end users or stakeholders. This criteria may include performance requirements, standards, scenarios, and rules of system behavior. The testing team uses acceptance criteria to verify that development is complete. Once these parameters are met, the story or feature is considered “done.”
How to Write an Effective User Story
Writing your first user stories can be difficult, especially since they are the basis for your product’s functionality. User stories are most commonly developed during the initial stage of development and used in the planning of iterations and sprints, but they can be created at any point (at inception, to provide a scope of the entire project/solution; in construction, to identify new stories, remove unnecessary stories, and break stories into smaller pieces; transition) and added to the backlog for the next iteration.
The following 10 tips will help you create effective user stories:
Put Users First: The purpose of a user story is to demonstrate functionality from a user’s perspective. Be sure to interview or survey users and include user-defined, factual information. In some cases, the user may not be a person, but rather a system.
Define Personas: Understanding your users is an essential element of writing a user story. Create fictional characters that represent your target end-users (these may include consumers, buyers, frequent shoppers, accountants, HR professionals). Buying behaviors, problems they are seeking to solve, and overall goals are all important pieces of information to have about your ideal customer. Use these persona names rather than the generic user role when writing your stories.
Collaborate: Be sure to get all relevant stakeholders in a room to collaborate during user story creation. Product management, engineers/developers, testers, customer support, sales, and the customer should all be represented.
Maintain Simplicity: Keep the story simple and clear. Use an active voice and focus only on important facts.
Start with Epics and Refine: Begin with a larger user story to fully understand the overall functionality, and then drill down into the details of the actual feature. Each step in a larger process should become a unique story. This process allows you to make the story fit into a single sprint or iteration.
Include Acceptance Criteria: Write acceptance criteria that define what constitutes “done” for that particular story. The acceptance criteria are a perfect contributor to test cases that the testing team will use to ensure the feature is ready for the user.
Start with Post-it Notes or Index Cards: When user stories first emerged as part of Extreme Programming (XP), they were captured on simple index cards. Using this method encourages collaboration and discussion, visibility and transparency, and is an easy way to move things around and storyboard in a collaborative setting.
Display User Stories in an Accessible Area: Making the user story visible in an open area, such as a wall or whiteboard, encourages collaboration throughout the development project. The story display may be enhanced with diagrams, mock-ups, workflow diagrams, story maps, and sketches.
Embrace Feedback: Agile development embraces flexibility. Feedback allows you to refine functionality to ensure the product is delivering value to the user.
Include Time Estimates: The time it takes to complete development based on a user story is important for planning iterations and releases. Time estimates can aid in assigning tasks and subtasks to team members.
There are two main techniques that can aid you in writing user stories:
Three Cs: Pioneered by Ron Jeffries in 2001, the Three Cs formula includes, a card or post-it note, a conversation between the users, developers, testers, and product owners about the feature, and confirmation that the goal has been met.
INVEST: This criteria, introduced by Bill Wake in 2003 and popularized by Mark Cohn’s book, User Stories Applied for Agile Software Development, evaluates the value of a user story by ensuring that it is independent (can be developed in any sequence), negotiable, valuable (to a user or business), estimable (for completion), small (design, test, and code in a single iteration), and testable.
To learn more about writing a user story and get tips and templates to help you get started, read How to Write a User Story in Software Development that Actually Focuses on the User.
Who Writes a User Story?
It is not necessarily about who writes the user story, but who is involved in the process of developing the user story. The goal is a collaborative discussion that results in a user story. Product management, engineers/development, testers, customer support, sales, and most importantly, the customer should participate in the process. The product manager or product owner typically owns the user stories throughout the development lifecycle.
What Is the Definition of Done in Agile?
Each team will have its own definition of done or complete in Agile development, and this definition may vary based on what is being evaluated for completeness — a user story, sprint, or full release. There are criteria that can be put in place to ensure a feature or function is truly complete. The checklist of criteria may include the following:
Is the code written?
Has the code been tested?
Does the feature meet the acceptance criteria?
Does the feature integrate and function with the existing solution?
Have the product technical specifications been updated?
Has the product documentation been updated?
Are Use Cases and User Stories the Same?
The terms user story and use case are similar, but use cases contain much more granular detail compared to a user story. A user story is written during a collaborative discussion and represents the perspective of a user, includes the user’s goal, and acceptance criteria.
Are Use Cases and User Stories the Same?
The terms user story and use case are similar, but use cases contain much more granular detail compared to a user story. A user story is written during a collaborative discussion and represents the perspective of a user, includes the user’s goal, and acceptance criteria.
This same information is included in a use case, but the use case goes even deeper and outlines functional requirements of the solution, including all avenues of user/system interaction and possible risks. Many development projects will integrate user story creation, story mapping, and use cases to build a complete and thorough product.
User Story Examples, Benefits, and Challenges
User stories are typically written based on functional attributes. For example, “As a customer, I want to deposit a check electronically, to avoid driving to the bank or ATM.” However, there are non-functional characteristics, or technical constraints, that are also important. Using this same banking example, the more technical constraints may be written as follows: “As a customer, I want to deposit 12 checks in a single electronic transaction.” Understanding the specific details (that may seem more technical) enables the development team to think about the constraints they may have to place on an open-ended user story to make it feasible.
User story templates and other Agile templates are available for download here.
User Story Benefits
User stories are a common element of Agile development, and using them properly provides extensive benefits to those who are developing the solution and the customer using the software.
Customer Benefit
Find increased value in the software solution.
Build a positive, collaborative relationship with vendor.
Increase satisfaction.
Eliminate technical details in order to include customers and non-technical stakeholders.
Focus on customer needs.
Software Vendor Benefit
Increase competitive advantage.
Encourage collaboration and cooperation.
Boost transparency.
Reduce risk.
Increase customer satisfaction.
Focus on value.
Avoid unnecessary adjustments to the backlog.
Eliminate technical details that may hinder collaboration.
Develop creative solutions.
Support the flexibility of Agile development.
User Story Challenges
As with any business project, there are challenges that arise. Mike Cohn’s book, User Stories Applied for Agile Software, identifies the core problem in software development with this simple observation: “Software requirements is a communication problem.” The user story development process is intended to remedy this challenge, but the increase in communication can seem tedious to some internal stakeholders.User Story Challenges
Additional challenges include the following:
Ensuring the user story is comprehensive enough to demonstrate value, but simple enough to develop in a single iteration.
Focusing on how to build and include technical details that are unnecessary at this stage of development.
Conversations and collaboration can seem time consuming and daunting.
User stories help shift software development organizations from a biased, requirements-driven approach to a collaborative, user-centric approach. They are simple, straightforward, and representative of the customer’s expectations. This tactic encourages conversations between internal stakeholders and customers, resulting in a more competitive product that is valuable to the most important people in your business, your users.
Improve Visibility into User Stories with Smartsheet for Software Development
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.