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 own 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

• Obstacles when creating user stories

• User story examples with acceptance criteria

• 4 user story templates

• Download user story templates

• Best practices for creating user stories

• Making the most of user stories with Pluralsight Flow

A user story describes product features from the end user’s perspective. Product managers and product designer 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 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 member 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 think up new solutions by asking questions and reaching a shared understanding. 

• The confirmation: Product managers and designers need to lay out acceptance criteria that meets 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. As a result, some devs 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 user 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 and not 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 refers 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 is 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

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.

To help you write better user stories, we’ll present a few examples. 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 teacher wants to organize test scores as they record them. 

Acceptance criteria: Given the teacher wants grades ordered, when a program automatically ranks all the scores, then the teacher can identify students with the lowest scores. 

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 the author wants acclaim, when they successfully promote their book, then they can boost their popularity. 

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 spreads the word online. 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 the salesperson works in a difficult market, when they find better leads, they stand a better chance of making sales. 

Takeaways: Sometimes knowing your user isn’t enough. It’s one thing to write about a salesperson; it’s another to write about one in a difficult field. The extra context helps explain how a dev’s tools can help end users reach their goals. 

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

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

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. 

Putting together a user story highlights your product's value to customers. That said, the benefits continue after making your user story template. Thinking about the end user’s story and acceptance criteria will ensure you meet all their requirements. While the process takes time and thought, user story templates pay for themselves in customer retention and satisfaction.

Once you have your user stories in place, it’s time to create the features your story outlines. A tool like Pluralsight Flow can help you track how your team is mapping to goals, identify blockers keeping devs from completing acceptance criteria, and look for ways to improve your process along the way. To find out more, schedule a demo with our team today.