Creating a new product or implementing a new feature should be rewarding and encourage innovation. However, when a development team is instead stuck writing lengthy requirements documentation with suffocatingly rigid guidelines, that may not always be the case. Traditional software development methods relied heavily on following a predetermined set of requirements for each unique feature of a given product, service, or application. This locked teams into strict guidelines, allowing for very little flexibility to make adjustments on the fly based on real time data or customer feedback.

Then in the late nineties, development teams began adopting agile project management methodologies and the idea of a customer-centric “User Story” was born.

A User Story is a brief, 2-3 sentence description of one or multiple features of a given software system from the perspective of the customer/end user. User Stories are written in “plain language”, meaning there are no overly technical terms so it could be easily read and understood by everyone – not just the developers. For example, a User Story for an exercise or workout app could be something such as, “As an iOS user, I want to sync data with an Apple Watch so that I can track calories burned more accurately.”

These descriptions could be written by any one or multiple stakeholders, including the development team, managers, or clients/users. Because user stories are intended to be flexible and reflect the needs of the user, they were often written on a notecard or sticky note and regularly revised or changed.

By creating simplified and relatable requirement descriptions, development teams were able to focus on quickly delivering the features and updates that their users wanted.

What is a User Story in Agile?

Imagine planning a road trip, but having to list out each and every direction before even leaving your house. Then once you left, you had to follow those directions even if a better route or an amusing tourist attraction popped up along the way. That’s a bit how things used to be before agile software development. 

User Stories were created to replace the need for traditional requirement documentation, which took teams forever to write and often handcuffed developers to just one way of doing things from the very start. All requirements had to be detailed out during the planning stage, and developers were stuck following these requirements despite any changes or issues along the way. User Stories help to simplify how developers and production teams work on new product updates and features by emphasizing small, regular updates based on what the end-user will benefit from the most.

In the words of Mike Cohn, an original founder of agile and scrum methodologies, a user story should “shift the focus from writing about requirements to talking about them.” The Extreme Programming (XP) author and creator believed it was more beneficial for development teams to adopt a “just enough” approach that focused on delivering consistent value to users.

Agile user stories provided teams with much more flexibility and allowed them to continuously deliver new features and updates to their customers – often in real time. Rather than large product releases, agile software development emphasized breaking deliverables into smaller, more manageable chunks that kept customers excited and the product backlog moving forward. This also helped to avoid the common problem of revealing too much and being stuck working on something that may not be in the user’s best interest.

Stories, Epics, and Initiatives: How Agile User Stories Keep Projects Moving Forward

In agile methodology, User Stories are a part of what is called an Epic. Epics detail a larger body of work that is then broken down into individual User Stories. These Epics then fall under the umbrella of an even bigger picture Initiative, containing multiple related Epics and their User Stories. Initiatives and Epics allow teams to organize different User Stories based on shared goals.

Let’s go back to our example from earlier with the imaginary workout app. Our example User Story detailed how an iOS user may want to sync data from their Apple Watch. However, a separate User Story could focus on Android users and other fitness trackers. Both User Stories could then fall under an Epic such as “Improve Fitness Tracking Functionality for Q1 Launch.” In this case, the overarching Initiative may be “Increase Users by 3%”.

Together, User Stories help to drive Epics forward, which ultimately allows teams to complete full Initiatives with continuous improvements for the end user. Teams are then able to deploy updates more frequently and even respond to user and customer requests more quickly.

The Benefits of Agile User Stories

There are four major benefits to adopting agile user stories over traditional requirement documentation:

1. Increased flexibility for the development team. User stories free up the development team from needing to follow rigid and restrictive documentation written in the beginning of the production process. This prevents locking developers into a single solution, and allows them flexibility to work on innovative features and updates.
2. Software updates are faster. Agile development focuses on deploying small, yet consistent new features and updates rather than the larger traditional all-at-once approach. This keeps the development team motivated by ensuring the product backlog is moving forward. Plus, developers no longer have to spend their time writing long and exhaustive requirement documentation.
3. Teams are able to focus on what matters most – the user. User Stories help production teams focus on the features that are most meaningful to the user. They allow teams to also more quickly respond and react to user demands in real time since updates occur in smaller segments. The intention of User Stories is for teams to truly take a step back and understand what it is that users want and need from the given service.

The 3 C’s of User Stories

Another XP creator, Ron Jeffries, popularized the idea breaking down User Stories into what he referred to as “The 3 C’s”. According to Ron, User Stories should all contain these three essential elements:

Card

The Card is the short 2-3 sentence description of the specific User Story. The card must address the who (a specific user role), what (the desired task or action), and why (the benefit of completing this task or action).

Conversation

The Conversation represents a promised discussion between all stakeholders – including the end user, production and development teams, and the Product Owner. The goal of this collaboration is to establish a shared understanding and determine the value of the individual User Story. What is discussed during this Conversation should be reflected in what is written for the Card.

Confirmation

The Confirmation is an acceptance test in which the Product Owner confirms that the User Story has been satisfied based on a predetermined definition of “done”. It represents the specific conditions that must be met in order to fulfill the goals of the User Story.

How to Begin Writing User Stories

Once you are ready to begin writing User Stories, there are a few key items to keep in mind.

1. Talk to Your Users: It may sound obvious, but one of the best ways to begin creating User Stories is to have conversations with your users. This way you can figure out what they are wanting from your product or service, and what you can do to keep them happy.
2. Determine a Definition of “Done”: This is how the Product Owner will determine whether the User Story has been completed and that the outlined task can now be achieved by the target user.
3. Define the Who: The “who” should address a specific role that the User Story is intended for. The role should reflect a real end user (such as the iOS user in our example), which does not include members of your team such as a developer. If there are multiple user types, you may want to create multiple stories.
4. Define the What: The “what” represents an action or specific task. In our example, the action is syncing data with an Apple Watch.
5. Define the Why: The “why” should describe the benefits of the user story, such as achieving more accurate calorie tracking in our example.
6. Write User Stories in Plain Language: User Stories should be easy to follow and understand. They should clearly reflect the perspective and wants of the target user without being overly complicated.

User Story Examples and Templates

Most User Stories follow the same basic format or User Story template.

“As a [who/role], I want to [what/action] so that I can [why/benefit].”

Our example from earlier falls right into this outline: “As [who: an iOS user], I want to [what: sync data with an Apple Watch] so that I can [why: track calories burned more accurately].”

This template can be applied to all sorts of different products and even specific user types within that product. While this specific structure is not necessary, it can help get you started on thinking about which User Stories are needed for your product. 

Don’t be afraid to create multiple User Stories – in fact, it’s encouraged! By organizing your User Stories within encompassing Epics and Initiatives, your team can ensure steady and ongoing product improvements that reflect the wants and needs of your users.