For software devs, it's easy to focus on what you're making and forget who you're building software for. While the Agile methodology stresses the importance of feature requirements, the end user should be top of mind throughout the entire software development process. Thankfully, you can frame these requirements in a short, simple description. We call these templates a user story.

Creating user stories helps devs understand the problems they’re solving for users and how to make their tasks easier. With simple, non-technical language, you can establish the value behind a piece of software. Not only will this help teams understand what they're making, but also why it matters. 

Below, we’ll break down the elements of a good user story and provide free templates for you to perfect your user story process.

Table of contents:

• What is a user story?
• Why are user stories important?
• The INVEST approach to user stories in Agile
• How to write user stories
• 4 user story templates
• User story examples with acceptance criteria
• Get started with Flow’s user story templates
• Obstacles when creating user stories
• Best practices for creating user stories
• FAQ

A user story describes product features from the end user’s perspective. Product managers and designers write these brief stories to convey why users need or want certain functionality. Within the range of Agile team practices, user stories are the smallest unit of work, so they are intended to be specific.

Three elements go into creating user stories, known as the three C’s: 

• The card: This is the physical place where you write a user story. Placing the story on a physical card helps cement for team members the criteria and user problem it’s solving. 

• The conversation: User stories inspire team discussions on how to meet the user requirements. Your team can brainstorm new solutions by asking questions and reaching a shared understanding. 

• The confirmation: Product managers and designers need to lay out acceptance criteria that meet user requirements. Once your team wants to proceed with a solution, devs move forward with this confirmation. 

Note: Some teams add a fourth “C” for “context” on more complex stories.

User stories consist of one or two sentences. In that space, they describe end users who earn value through your product. The user story format reads: "As a [user], I want to [goal] so that [benefit]."

Let's explore that format in more detail:

• As a [user]: Explain who you're building this product for. Go beyond job titles and cliches, and capture the user's inner sense of value. If your organization uses buyer personas, you can apply a specific one here.  

• I want to [goal]: Describe the user’s intentions rather than how they get there. The goal matters more than implementation.

• So that [benefit]: Break down how meeting a goal benefits the user. Remember to look at the bigger picture or a deeper desire in users. 

Bear in mind that teams can use other user story formats. Some popular options include: 

• In order to [receive benefit] as a [role], I can [goal/desire].

• As [who] [when] [where], I [want] because [why].

Depending on the complexity of your user stories, they may fit into different categories. Sometimes, you can even combine user stories into a larger narrative. Below are the four main types of user stories:

• Simple: These are individual or self-contained user stories that focus on a particular user or type of product. 

• Epic: Groups of related user stories come together to form epics. They may involve multiple users working together or independently or multiple needs for a single type of user to achieve some goal or benefit. 

• Thematic: These are major investments and strategies that group epics together. Thematic user stories highlight how a company will achieve wider goals. 

• Scaled Agile Framework (SAFe): These user stories add extra details such as a benefit hypothesis, cost of delay, or nonfunctional requirements. 

User stories help devs focus on the end user. Instead of thinking about their product in a vacuum, user stories capture functionality from an outside perspective. So instead of thinking about what a tool does, devs consider how it helps users. 

User stories also play a key role in Agile development by:

• Providing a sense of structure

• Highlighting a user’s needs and priorities for devs

• Pointing out the actual value found in a product

• Exploring the "who," "what," and "why" in development to give devs essential context 

From a distance, user stories can sound like product requirements. While both of these descriptions help explain a product, they go about it differently: 

• User stories focus on how your product meets users' intentions and core values.

• Product requirements outline the functions a product performs in itself. Some teams outline product requirements within their acceptance criteria, so some developers use the terms interchangeably.

Teams generally write user stories early in development. This way, they can pinpoint how their tool satisfies a core need and work backward. By contrast, teams write product requirements later in production. These requirements focus less on the user and more on how the product works in isolation.

Bill Wake created the INVEST approach to describe qualities that make a good user story. Specifically, he shaped his criteria to assist Agile development teams. Below are the qualities that make up a good user story: 

• Independent: Each user story should stand on its own. Your workflow shouldn’t depend on moving through user stories in a certain order. 

• Negotiable: Teams must collaborate to outline customer priorities. Your final user story relies on in-depth discussions and revisions.

• Valuable: User stories point out where you can add value to your product. If your user story doesn't add enough value, it's a sign you should go back to the drawing board. Higher-value stories also take precedence over low-value ones.

• Estimable: You should estimate the size and time frame of each user story. This helps prioritize one story over another. If you can't assess whether a story is high or low effort, reassess how you break down Agile user stories. 

• Small: User stories capture the essence of a user’s needs. Instead of tallying technical facts and pain points, treat them as a goal to collaborate around to assess minute yet meaningful details.

• Testable: You want testable requirements for user stories. If your story doesn’t include testable acceptance criteria, it can’t help you. 

Despite their usefulness, some developers need help finding their footing with user stories. Thankfully, you can write one in just four steps: 

Before anything else, ask who your product is for. Then, you can define your ideal end user by writing a user persona. These personas may not represent all of your users, but they should contain qualities found in most users. To define your end user, ask:

• What attitudes and behaviors will the end user have?

• What is your end user’s job or field?

• What are their core responsibilities in their job?

• Do they have attributes that affect how they use the product?

• What user decisions will your product affect?

Once you know who the user is, you need to learn what they want, expect, or need. On top of that, consider how your product helps them achieve their goals. To break down what your users want, try:

• Reviewing customer feedback on your products and similar products

• Conducting market research in your field

• Talking to your customers or folks that align with your end user

• Identifying problems your product can fix

• Asking team members how they would use your product

Now that you understand your users and what they want, you can write out the third part of a user story. Specifically, take what you know about the user and describe how solving for this user’s want in your product helps customers achieve their goals. You also want to hone in on how this process creates value for your users and why that benefit matters to them. 

When writing a user story, be sure to: 

• Prioritize the user wants that would provide the greatest value.

• Use an appropriate user story template.

• Focus on what your product does for users rather than how it accomplishes this. Focusing less on how it works will give your developers free rein to find the best solution. 

• Keep the story specific but succinct.

Within the Agile methodology, acceptance criteria refer to the conditions resolving a user story. Some devs  refer to these conditions as product requirements or “definition of done.” For example, if your product fulfills all the functions a user needs to meet their goals, it meets the criteria. Your story may also involve more than one acceptance criterion. 

Acceptance criteria are usually written in this format:

• Given that [how the scenario begins], when [the user takes an action], then [the effect of their action].

Make sure your acceptance criteria:

• Meet the requirements before shipping your product

• Are measurable and testable

• Fit in with the user's deeper needs rather than a series of boxes to check off

• Fit in with the user's perspective, not yours

To help you write your own user stories, we’ll explore different templates and what they offer. 

Simple user stories focus on one scenario at a time. This lets you hone in on one user's issues and outline clear acceptance criteria. Some teams add a priority and an estimate to the story:

• Priority: This refers to the value attached to user stories. Agile teams usually tackle stories with greater priority first.
• Estimate: This refers to the overall effort needed to complete a job or product.

Epics are groups of related user stories that tie into larger narratives. For example, epics may follow different employees at the same company or users applying a program for different uses. Epics help track categories of users instead of individuals. 

Thematic user stories go beyond epics to track larger business initiatives. Thematic templates place your organization's strategies at the forefront. To this end, unlike epics, they consider factors like priority, estimate, and release. Here, release refers to functions you want to deliver to users at once.

Certain Agile developers like to include extra details in their user stories. These additional points help you understand Agile at a deeper level. SAFe user stories include factors like: 

• Benefit hypothesis: Statements you can validate about a feature’s benefits
• Nonfunctional requirements: System qualities that don’t directly relate to their functionality
• User business value: The task’s importance relative to the user and your business’s income 
• Cost of delay: The value lost from releasing a product later
• Time criticality: The importance of finishing a task as soon as possible
• Job size: The number of employees and resources needed to finish a job
• Risk reduction/opportunity enablement value: Values referring to a job's ability to mitigate risk or create more work opportunities later
• Weighted shortest job first (WSJF): A task prioritization algorithm based on the cost of delay divided by the job duration

We'll present a few examples to help you write better user stories. In each case, we’ll explain the structure of the story, the acceptance criteria, and some takeaways. 

Scenario: This basic scenario explains who a user is, what they want, and why. In this case, a shopper wants to view weekly specials within a grocery app to save money.

Acceptance criteria: Given that the shopper wants to view weekly specials when they shop in the app, then the weekly specials section should be prominently displayed on the home screen.

Takeaways: Goals and benefits don’t exist in isolation. Both tie into the user and have an almost collaborative relationship. The goal enables the benefit, not the other way around.

Scenario: This story forefronts the user’s deeper desires ahead of the tangible goals that will get them there. 

Acceptance criteria: Given that the home cook wants to discover new dishes easily and add necessary ingredients to their shopping list, when shoppers use the grocery app then it should feature a searchable database of recipes categorized by cuisine, dietary preferences, and meal type.

Takeaways: This user story highlights how a user’s benefits and goals come before functionality. Don’t lose yourself in the mechanics of how a program performs a function. Instead, think about it in the context of the ultimate goal.

Scenario: This scenario uses the five “W” question format: who, what, when, where, and why.

Acceptance criteria: Given that the busy parent doesn’t have much time to cook when a busy parent uses the grocery app to order food quickly, then they should be able to spend more time with their family.

Takeaways: Sometimes, knowing your user isn’t enough. It’s one thing to write about a busy parent; it’s another to understand their motivations. The extra context helps explain how an app can help end users reach their goals.

Ready to use these user story templates on your own? Download our template below for Google Sheets to create custom user stories based on your products and customers' needs. 

Thanks to their simplicity and usefulness, there aren’t any real downsides to making user stories. That said, some devs run into pitfalls by focusing on the wrong details. Here are a few potential obstacles to keep in mind:

• Creating a checklist: User stories aren’t a list of tasks. Treat your story like a short narrative and not a series of instructions. 

• Ignoring small details: Users’ goals and desired benefits live in the details. Don’t treat the user story like a broad overview—use it to springboard into their detailed perspective. 

• Abandoning the story: All too often, devs write a great user story that gets sidelined. Throughout development, keep the user story in mind. Focusing on the user’s sense of value helps hone in on the best product features and additions.

Some best practices for putting user stories together include:

• Collaborate across teams: The more team members involved in your story, the richer they become. Different perspectives can shape how you frame user goals and pain points. 

• Empathize with your users: When making a user story, give your users a name and internal traits. You aren’t creating an abstraction, so make them feel like real people you know. Base these off real customers you’ve talked to.

• Focus on what users want, not implementation: Lay out the user’s needs, not how you’ll meet them. You can’t reduce user stories to a series of boxes you check off. 

• Keep your stories simple: You want every user story concise, clear, and easy to understand. Avoid ambiguity and complexity to focus on the essence of a user’s needs.

• Use impact mapping: Impact mapping ties user stories to goals, actors, impacts, and deliverables. These categories answer the why, who, how, and what questions related to your stories. 

User story templates aim to help you understand problems and solve user challenges, but you may have a few more questions about how to best use them. Here are some common questions about user story templates.

The standard user story template is: "As a [user], I want to [goal] so that [benefit]." Following this template, you can create a story explaining who the product was designed for, its overall goal, and why the user in question desires it.

When creating a user story template, the three C's of user stories are the card, the conversation, and the confirmation. The card is the physical place where a story is written, the conversation is the idea brainstormed by the process, and the confirmation is the acceptance criteria to meet user requirements.

A user story template should convey user requirements in an easy-to-read format. Limit your story to a sentence and keep it simple enough for anyone, not only developers, to understand. Adding too much information may distract from the primary goal of the story template.

A user story is a brief statement that describes a user's required functionality. A use case, on the other hand, is a detailed description of how a system user will achieve their goal. While both help provide context for developers to ensure they meet user expectations, use cases provide a much deeper level of detail than a user story.  

Once you have your user stories, it’s time to create the features your story outlines. A tool like Pluralsight Flow assists with your software delivery process, helping you track how your team maps goals and how you can improve your strategy.

Flow connects with tools your teams use daily—like GitHub, Jira, and ADO—to provide you with an aerial view of what’s happening across your engineering team. From there, Flow makes it easy to turn data into actionable insights to improve your process, identify inefficiencies, and streamline your software delivery lifecycle. 

To find out more, schedule a demo with our team today.