User stories — examples and templates
If your team has explored the Agile project management framework, you’re probably familiar with user stories. However, even if you’ve created a few user stories of your own, examining how other companies and teams write them can provide valuable inspiration and fuel your creativity.
With that in mind, we’ve compiled a list of 15 user story examples, which will give you an understanding of what good ones look like and provide fresh ideas for your own creative process.
This guide will cover:
- What a user story is
- User story examples
- User story examples in different mediums
- User story examples within the Agile framework
- User story examples for each stage of the customer journey
- How to get started with user stories today
What is a user story?
A user story is a brief, general explanation of a specific software feature written in plain language from a customer or end user perspective. The purpose of a user story is to help you better understand the customer journey and how consumers will likely interact with your product. One of the main benefits of using these stories is the ability to give developers context — the “why” — for what they’re creating.
A standard user story is short — typically only about a sentence long — and serves to specify a user, an action, and a desired outcome. They’re written in simple, everyday language from the perspective of the user.
Here’s an illustrative example:
As a reader, I want to read this Adobe guide so I can find successful examples of user stories.
This example follows the tried-and-true user story template. As a [insert user type], I want to [offer a specific action] so I can [identify a value or objective].
As you’ll see in our examples, user stories don’t go into technical details about the project. Therefore, your team should be as creative as possible when thinking about how users could interact with your product.
Creating user stories doesn’t have to be a formal process. You can simply write each user story on an index card or sticky note. Alternatively, you can create and organize them using digital tools like Microsoft Word, PowerPoint, or Excel.
Any member of your Agile team can create user stories. However, the Product Owner is ultimately responsible for deciding on user stories and prioritizing them in the Agile product backlog.
Get more out of your user stories with the 3 Cs
Regardless of who’s creating the user stories, they should follow the 3 Cs, which are:
The card is where you write the user story. It represents the first stage — the first C — in creating user needs. The card must contain just enough information for the team to understand the story and to plan actions or work around it. The story card should always incorporate a user, action, and outcome.
After creating the card, your Agile team can move on to the second C — conversation. This is when everyone can let their creativity flow to step into consumers’ shoes and further explore their needs.
The final stage of the 3 Cs model is confirmation. During this stage, stakeholders will evaluate the story using acceptance criteria. Using the 3Cs model will help your team effectively express the customer’s perspective and create better user stories.
Create user stories effortlessly with INVEST
INVEST is a useful acronym to help you create good, impactful user stories. It stands for:
- Independent. Independent stories reduce dependencies on other features, which means they’re easier to test.
- Negotiable. This refers to the functionality of the feature, which can be negotiated between the project owner and team.
- Valuable. The feature described in the user story must provide clear value to end users.
- Estimable. Stories describing features that are overly vague or too large are not estimable.
- Small. User stories should be able to be completed in a single sprint by the dev team.
- Testable. Stories must be testable in order to determine their success — the acceptance criteria should be simple and objective, with clear pass/fail scenarios.
Leveraging tools like INVEST and the 3 Cs model will enable your team to tap into the many benefits of creating user stories, such as boosting collaboration, supporting backlog prioritization, and minimizing risks during feature creation.
User story examples
User stories are an incredibly versatile tool that can help your team take advantage of Agile project management methodology more effectively. To illustrate this versatility, we’ve grouped our 15 user story examples into three categories:
- Element of the Agile framework
- Stage of the customer journey
When incorporating user stories into your Agile workflow, you can model the example that best aligns with the unique demands of your project.
User story examples in different mediums
Index cards and Post-it Notes are analog classics for drafting user stories. But these days, digital templates can also be helpful and may work better for your team, depending on how you prefer to do things. Digital user story cards can be especially useful for remote or hybrid teams.
Gloriously uncomplicated, the humble index card is a traditional format for composing user stories. Index cards can be passed around the group for viewing and editing and can be hung on the wall. These cards are also great for jotting down stories when you’re unexpectedly struck with a spark of inspiration.
Instead of wasting time launching your application or finding the appropriate Microsoft Word document, you can grab a pen and paper to jot down your idea before it slips away.
Here’s an example of a user story you could write on your index card:
As a project manager, I want to review workflow management software so I can choose a new platform for my team.
Index card with acceptance criteria
User stories often include acceptance criteria, which is essentially what you would need to do to achieve the user’s goal. When using the index card method for user stories, you can include acceptance criteria on the back of the card.
Let’s stick with the example above. Whereas the front of the card would list the user story, the back of the card would contain acceptance criteria, such as:
- Ensure that user reviews and testimonials are published on our product site.
- Verify that user reviews for our product are available on third-party forums.
- Proactively acquire new user reviews by sending feedback requests to current users and past clients.
By doing all this, you can ensure that reviews about your product are readily accessible.
While a physical index card is great for in-office work, a shared document is better for drafting, editing, and viewing user stories remotely. There are several templates you can download to make creating user stories in Word easier. Alternatively, you can create your own.
Once you have your template or table in place, you can craft concise but effective user stories like the following:
As a product subscriber, I want to be able to cancel my monthly membership using self-service tools.
Using Microsoft Excel, you can easily organize and keep track of your user stories in one central location. Let’s stick with the previous user story, which read as follows:
As a product subscriber, I want to be able to cancel my monthly membership using self-service tools.
In addition to including the story and acceptance criteria in your Excel spreadsheet, you can create cells for other information. For instance, you could include cells like:
- Cost of delay
- Benefit hypothesis
- Time criticality
Including a cost of delay in this product subscriber user story, for instance, could outline what costs the business would incur if it did not promptly implement self-service tools for canceling subscriptions. It could be written as such:
A six-month delay in implementing new self-service tools could result in a missed opportunity of hundreds of trial subscribers.
You could construct a benefit hypothesis for this user story as follows:
If we allow users to cancel via self-service tools, they may be more apt to sign up for a trial subscription because they won’t feel “trapped.”
The time criticality for this user story may read something like:
The longer we wait to implement self-service tools, the more quality leads will exit the trial subscription funnel.
Microsoft PowerPoint is another excellent way to create and showcase user stories. PowerPoint is especially beneficial if you plan on presenting your user stories to an audience, such as a panel of stakeholders.
The most pragmatic approach within PowerPoint involves placing the user story, acceptance criteria, and any other information all on a single slide. You may also want to include on that same slide the story type (e.g., discovery, purchasing) and an importance score.
You can score stories using a numerical scale or simply identify them as mildly, moderately, or extremely important. Alternatively, you can assign Scrum points, a measurement unit that estimates the effort required to complete a user story.
You can also classify user stories based on the stage of the customer journey that they address or influence. Some common user story types include:
- Registration or sign-up stories
- Purchasing stories
- Retention stories (i.e. app feature updates that keep users engaged)
You could list our example about software subscription cancellation as either a registration story or a purchasing story. Either way, this user story would rate highly on the importance scale, as it has a significant impact on a prospect’s purchasing intent.
User story examples within the Agile framework
User stories are part of the larger scope of the Agile framework for project management and product development. The Agile framework includes epics, product features, and user stories, as well as technical stories. The user story format can apply to all of these elements in the workflow.
Let’s take a look at how the user story format can apply to each of these elements.
Epics are larger projects within the Agile framework. Completing an epic could require multiple project features and several user stories to be finished along the way.
Like user stories, epics follow a general format that includes a user, an action, and desired outcome. They’re also relatively short. However, epics are much broader in scope, which is why multiple stories must be created for each one.
Here’s an example of an epic:
As a project manager, I want a robust work management platform that empowers my team to take advantage of the Agile methodology.
Once you’ve developed your epic, you can create more specific user stories to achieve your objectives. For instance, you could create a user story to identify specific team members, tools, and what they hope to accomplish with those tools.
To accomplish our project manager epic, the dev team would need to create multiple features. As you’ll notice, each of the following examples describing features adheres to the same user-action-expectation and outcome format:
- As a project manager, I want to access detailed reports and visuals so I can stay apprised of my team’s progress.
- As a project manager, I want workflow automation tools so I can boost productivity and efficiency.
- As a project manager, I want to drive better collaboration to achieve measurable business outcomes.
These feature-oriented ideas will help a project management platform development team better understand the needs of its target audience. The team could expound on these concepts to map out the features and tools within their project management software.
User stories are on scale with product features in terms of scope. However, they’re more about the user’s experience and less about how the action will be accomplished technically.
Notice the subtle differences between these stories and the feature-centric ideas above:
- As a project manager, I want to access detailed reports to guide decision-making processes and improve information transparency.
- As a project manager, I want to automate traditionally tedious processes so I can reduce my team’s workload and boost morale.
In these stories the project manager is still the user, but the action and desired outcome are more about their team and having positive experiences when managing work.
Technical stories are intended to support the epics, features, and user stories, which would all be classified as functional stories.
Technical stories can fit into a few different categories:
- Spikes — These stories require research to achieve the functional need of a customer.
- Refactoring — These stories are written to maintain the code.
- Infrastructure stories — These stories outline the modification or addition required to support a functional user story.
Here’s an example of a technical story:
As a project manager, I need a platform that includes machine learning and artificial intelligence tools (infrastructure) so I can use automation to boost management efficiency.
The user story format can also be applied to the product backlog. When using this approach, you don’t need to create new stories. Instead, you can group them together in order of priority.
For instance, the user story about the project manager that wanted reporting tools could be assigned three points, while the story about the project manager that wanted automation tools could be assigned four points.
In this scenario, your team may decide to focus on developing reporting tools first, as it will likely require less time and resources.
User story examples for each stage of the customer journey
Your users’ needs will shift as they move through their customer journey. The user stories you create can be structured in terms of where the customer or user is in the lifecycle.
Let’s look at some user story examples that correspond to various stages in the customer journey.
At this stage, users are just getting started on their journeys. As such, the questions they’ll ask will likely be broad and lacking technical jargon.
A discovery stage user story might read something like this:
As a software developer, I need a solution that centralizes important project information so I can collaborate with my cohorts more effectively.
At this stage, users are interested in a product or solution and are seriously considering signing up. But before they take the leap, your team must adequately address their objectives, expectations, and needs. These concerns may be related to pricing, ease of use or deployment, or security.
A registration-oriented user story might read as follows:
As a software developer, I want a platform I can start using almost immediately so that I can achieve a measurable impact on productivity and project outcomes.
If you want a high conversion rate, your purchase and sign-up process must be frictionless. User stories help you proactively identify these issues so you can minimize cart abandonment and drive more sales.
For instance, your purchasing user story could look like this:
As a project manager, I want custom, user-based pricing that delivers better value for my business.
When customers decide to subscribe to your platform or sign up for a free trial, it’s vital that you provide a smooth onboarding process. Doing so will help you maximize user retention rates and minimize churn.
Creating a user story like this one will help you view onboarding from the customer’s perspective:
As a project manager, I want to take a product tour of the workflow management solution so I can better understand how it will add value to my business processes.
The success of your product depends on your ability to acquire and retain customers. Achieving and maintaining a high retention rate demonstrates that you’re providing value for your consumer base.
A retention-oriented user story might read as follows:
As an ecommerce business owner, I want a solution that’s scalable so I can drive the long-term growth of my digital store.
Get started with user stories today
User stories are a helpful way of thinking about how users will interact with your product. As demonstrated by these examples, the user story framework is adaptable to whichever medium you prefer.
These micro-narratives can be applied to various parts of your product development cycle and any stage of the customer journey.
When you’re ready to put these examples to use, write down some concepts for your product, service, or company. To jump-start your process, share this article with your team and discuss how user stories could be helpful for your work.
Also, think about how user stories fit into your current workflow and whether any adjustments would be needed to accommodate and capitalize on user stories.
Adobe can help
Adobe Workfront is a powerful work management software that can help your team achieve its Agile goals. Workfront is enterprise work management software that connects work to strategy and drives better collaboration to deliver measurable business outcomes. By optimizing and centralizing digital projects, cross-functional teams can connect, collaborate, and execute from anywhere to help them do their best work.
To learn more, watch the overview video or take a product tour.