Agile User Stories: 40+ user story examples, formats and templates for product triumph!

A user story is a description of a feature / functionality described from the perspective of the end-user. User stories describe the users’ expectations of the system. User stories are described in Agile projects, and are organized in a product backlog, which is an ordered list of product functions. It is a concise, simple description of a feature or functionality that is written from the perspective of an end-user or customer. User stories are commonly used in agile software development as a way to capture requirements and guide the development process.

A typical user story includes three main components:

• the user,
• the action, and
• the benefit.

A typical user story is written like this:

As a <type of user>, I want to <achieve / perform some task> so that I can <get some value>.

Example of a user story for an e-commerce website might look like this:

As a customer, I want to add products to the cart so that I can checkout.

Another example:
As a customer, I want to be able to view my order history, so I can track my purchases and see when they will be delivered.

In this example, the user is the customer, the action is to view the order history, and the benefit is the ability to track purchases and delivery dates. User stories are usually short and simple, and they are written in a way that is easy for both developers and non-technical stakeholders to understand. They are designed to be flexible and open to negotiation, allowing the development team and stakeholders to collaborate and refine the requirements over time as new information becomes available.

When are user stories created?

User stories are typically created during the planning and requirements gathering phase of a project, which is usually done at the beginning of each development cycle in agile software development. This process involves working closely with stakeholders, including end-users, customers, and product owners, to identify the key features and functionalities that are needed in the software.

During this process, user stories are used as a way to capture and communicate requirements in a simple, easy-to-understand format. The development team works with stakeholders to identify the key user roles and personas, and to define the actions and benefits that are needed to meet their needs.

Once the initial set of user stories has been created, they are typically prioritized based on their value to the end-user and their impact on the overall project goals. This allows the development team to focus on the most important stories first, and to deliver incremental improvements to the software in each development cycle.

Throughout the development process, user stories may be refined and updated as new information becomes available or requirements change. This allows the development team to remain flexible and responsive to changing needs, while still delivering software that meets the needs of the end-users. Business analysts are usually the professionals who create user stories and capture requirements.

Analytics User Stories Examples – Agile requirements template and format

The following user stories are examples in the analytics domain. These include those for business intelligence like charts, and machine learning like sentiment analysis.

1. As a strategy consultant, I would like to review KPIs related to my domain, because that would help me understand the status of the business.
2. As a business manager, I would like to review progress over a period of time as a line chart, so that I can make necessary corrective adjustments.
3. As a SEO copywriter, I would like to generate positive-negative-neutral sentiments of my copy, so that I can write better effective and catchy articles.
4. As the president of the department, I would like to review charts of income and expenses, because I can determine the profitability of the department (and the security of my job?)
5. As the chief investment officer, I would like to have an aggregation of all spends and ROI, so that I can determine investment areas of greater return on investment.

Business intelligence user stories examples – Agile requirements template and format

Here are some examples of business intelligence user stories:

1. As a marketing manager, I want to view real-time dashboards of customer behavior and engagement, so I can optimize marketing campaigns and improve customer retention.
2. As a sales representative, I want to access detailed reports on customer interactions and sales performance, so I can identify sales trends and opportunities to improve performance.
3. As a finance analyst, I want to generate ad-hoc reports on financial metrics and KPIs, so I can analyze financial performance and identify areas for cost reduction and optimization.
4. As an operations manager, I want to monitor key performance indicators for operational efficiency, such as cycle time, throughput, and inventory levels, so I can identify opportunities to improve operational performance.
5. As a product manager, I want to track customer feedback and sentiment data, so I can identify customer needs and preferences and make data-driven decisions about product development and marketing.

E-commerce user stories examples – Agile requirements template and format

The following user stories capture various aspects of an e-commerce website from the perspective of the end-users (customers) and the store owner. They focus on the functionalities and features that are important for a seamless and convenient online shopping experience, while also addressing the needs of the business owner for effective store management and data analysis.

1. As a customer, I want to be able to search for products by category or keyword, so I can easily find and purchase the items I am interested in.
2. As a customer, I want to be able to add products to my shopping cart, view the contents of my cart, and proceed to checkout, so I can complete my purchase quickly and easily.
3. As a customer, I want to be able to create an account, save my payment information, and view my order history, so I can have a personalized shopping experience and easily track my purchases.
4. As a customer, I want to be able to view product details, including images, descriptions, prices, and customer reviews, so I can make informed purchasing decisions.
5. As a customer, I want to be able to apply discount codes, promotions, and gift cards to my purchase, so I can take advantage of special offers and discounts.
6. As a customer, I want to receive email notifications about my order status, including order confirmation, shipping updates, and delivery notifications, so I can stay informed about my purchases.
7. As a customer, I want to be able to provide feedback and reviews on products, so I can share my experiences and help other customers make informed purchasing decisions.
8. As a store owner, I want to be able to manage my product inventory, update product details, and track sales and revenue, so I can effectively manage my online store and make data-driven decisions about my business.

Media advertising technology user stories examples – Agile requirements template and format

These user stories highlight the key functionalities and features that are important for a media ad tech tool, covering the needs of different user roles such as media buyers, marketing managers, creative designers, publishers, data analysts, account managers, advertisers, and campaign optimizers. These stories focus on the capabilities that enable effective campaign management, performance tracking, ad creation, targeting, audience management, and optimization, among others.

1. As a media buyer, I want to be able to create and manage advertising campaigns, including setting campaign budgets, targeting criteria, and ad creatives, so I can effectively reach my target audience and achieve my marketing goals.
2. As a marketing manager, I want to be able to track and analyze the performance of my advertising campaigns in real-time, including impressions, clicks, conversions, and return on investment (ROI), so I can optimize my ad spend and make data-driven decisions to improve campaign performance.
3. As a creative designer, I want to be able to upload and manage ad creatives, including images, videos, and ad copy, in various formats and sizes, so I can easily create and update ads for different platforms and placements.
4. As a publisher, I want to be able to monetize my website or app by displaying ads from different advertisers, and to have control over the types of ads that are displayed, the frequency, and the placement, so I can generate revenue and provide a positive user experience.
5. As a data analyst, I want to be able to access and analyze ad performance data, including impressions, clicks, conversions, and audience demographics, in a visual and customizable way, so I can generate insights and reports to inform marketing strategies and optimizations.
6. As an account manager, I want to be able to manage multiple client accounts within the ad tech tool, including creating and managing campaigns, setting budgets, and providing performance reports, so I can effectively serve my clients and track their advertising performance.
7. As an advertiser, I want to be able to define and manage custom audiences, including demographic, geographic, and behavioral criteria, so I can target my ads to the most relevant audience and maximize my ad effectiveness.
8. As a campaign optimizer, I want to be able to use machine learning algorithms and predictive analytics to automatically optimize my advertising campaigns based on performance data, so I can improve campaign efficiency and achieve better results over time.

Customer Relationship Management (CRM) user stories examples – Agile requirements template and format

These user stories cover various user roles within a CRM tool, including sales representatives, sales managers, customer service representatives, marketing managers, executives, product managers, system administrators, and mobile salespeople. They address the functionalities and features that are important for managing customer relationships, sales activities, marketing campaigns, customer feedback, and overall business performance.

1. As a sales representative, I want to be able to track my leads, opportunities, and deals in a centralized CRM system, so I can easily manage my sales pipeline, prioritize my tasks, and close deals effectively.
2. As a sales manager, I want to be able to monitor the performance of my sales team, including their sales activities, deal progress, and revenue targets, so I can provide coaching, feedback, and support to improve their performance and achieve team goals.
3. As a customer service representative, I want to be able to access customer information and interaction history in the CRM system, so I can provide personalized and efficient support, resolve issues, and deliver a positive customer experience.
4. As a marketing manager, I want to be able to segment and target my customers and prospects in the CRM system, based on criteria such as demographics, behaviors, and engagement levels, so I can deliver relevant and personalized marketing campaigns to drive customer engagement and retention.
5. As an executive, I want to be able to access high-level dashboards and reports in the CRM system, so I can monitor overall sales performance, customer acquisition, retention, and lifetime value, and make data-driven decisions to drive business growth.
6. As a product manager, I want to be able to gather and analyze customer feedback and product usage data in the CRM system, so I can identify customer needs, preferences, and pain points, and incorporate them into product development and improvement strategies.
7. As a system administrator, I want to be able to configure and customize the CRM system to match our organization’s sales, marketing, and customer service processes, so I can ensure that the CRM tool is aligned with our specific business requirements and workflows.
8. As a mobile salesperson, I want to be able to access and update customer and prospect information in the CRM system on my mobile device, so I can manage my sales activities and update customer interactions on the go.

Enterprise Resource Planning (ERP) tool user stories examples – Agile requirements template and format

These user stories cover different functional areas within an ERP tool, including procurement, production planning, finance, human resources, sales, warehouse management, business analysis, and system administration. They highlight the key functionalities and features that are important for managing various aspects of an organization’s operations, such as procurement, production, finance, human resources, sales, inventory, and data analysis.

1. As a procurement manager, I want to be able to create and manage purchase orders in the ERP system, including selecting vendors, defining quantities, and tracking order status, so I can effectively manage the procurement process and ensure timely delivery of goods and services.
2. As a production planner, I want to be able to create and manage production schedules in the ERP system, including defining production orders, allocating resources, and tracking progress, so I can optimize production capacity and meet customer demand.
3. As a finance manager, I want to be able to manage financial transactions and records in the ERP system, including recording invoices, payments, and expenses, reconciling accounts, and generating financial reports, so I can accurately track and report on the financial health of the organization.
4. As a human resources manager, I want to be able to manage employee information, including hiring, onboarding, performance evaluations, and benefits administration, in the ERP system, so I can effectively manage the workforce and ensure compliance with company policies and regulations.
5. As a salesperson, I want to be able to create and manage sales orders, track customer orders, and view inventory availability in the ERP system, so I can efficiently process customer orders, manage order fulfillment, and provide accurate order status updates.
6. As a warehouse manager, I want to be able to manage inventory levels, including receiving, stocking, and picking inventory items, in the ERP system, so I can maintain accurate inventory records, optimize warehouse space, and ensure timely order fulfillment.
7. As a business analyst, I want to be able to access and analyze data from various modules in the ERP system, including sales, inventory, procurement, and finance, so I can generate insights, trends, and reports to inform decision-making and strategic planning.
8. As an IT administrator, I want to be able to configure and customize the ERP system, including setting up user permissions, defining workflows, and integrating with other systems, so I can ensure that the ERP tool is aligned with our organization’s business processes and requirements.

Create your own user story online

Savio Education Global User Story Generator · Streamlit (user-story-generator.streamlit.app)

INVEST in User Stories

Finally, all user stories must fit the INVEST quality model:

•         I – Independent
•         N – Negotiable
•         V – Valuable
•         E – Estimable
•         S – Small
•         T – Testable

1. Independent. This means that you can schedule and implement each user story separately. This is very helpful if you implement continuous integration processes.
2. Negotiable. This means that all parties agree to prioritize negotiations over specification. This also means that details will be created constantly during development.
3. Valuable. A story must be valuable to the customer.  You should ask yourself from the customer’s perspective “why” you need to implement a given feature.
4. Estimable. A quality user story can be estimated. This will help a team schedule and prioritize the implementation. The bigger the story is, the harder it is to estimate it.
5. Small. Good user stories tend to be small enough to plan for short production releases. Small stories allow for more specific estimates.
6. Testable. If a story can be tested, it’s clear enough and good enough. Tested stories mean that requirements are done and ready for use.

Best practices to write good user stories

Consider the following best practices when writing user stories for agile requirements:

1. Involve stakeholders: Involve stakeholders such as the product owner, end-users, and development team members in the process of creating user stories. This helps ensure that everyone has a shared understanding of the goals and requirements.
2. Focus on end-users: User stories should focus on the needs and goals of the end-users. It’s important to avoid writing stories that are too technical or feature-focused.
3. Use a consistent format: User stories should be written in a consistent format that includes the user, action, and benefit. This helps to ensure clarity and consistency across the stories.
4. Keep stories small: Keep user stories small and focused on a specific goal or outcome. This makes it easier to estimate, prioritize, and complete the stories within a single iteration.
5. Prioritize stories: Prioritize user stories based on their value to the end-user and their impact on the overall project goals. This helps to ensure that the most important stories are completed first.
6. Make stories testable: User stories should include clear acceptance criteria that can be used to verify that the story has been completed successfully. This helps to ensure that the resulting software meets the needs of the end-users.
7. Refine stories over time: User stories should be refined and updated over time as new information becomes available or requirements change. This helps to ensure that the stories remain relevant and useful throughout the development process.

By following these best practices, development teams can create effective user stories that help to guide the development process and ensure that the resulting software meets the needs of the end-users.

Prioritizing Agile User Stories

User stories are typically prioritized based on their value to the end-user and their impact on the overall project goals. Here are some common factors that are considered when prioritizing user stories:

1. User value: User stories that provide the greatest value to the end-users are typically given higher priority. For example, a user story that improves the user experience or solves a critical user problem may be considered more important than a story that adds a new feature.
2. Business value: User stories that have the greatest impact on the business goals and objectives are typically given higher priority. For example, a user story that increases revenue or reduces costs may be considered more important than a story that provides a minor improvement to the software.
3. Technical feasibility: User stories that are technically feasible and can be implemented easily are typically given higher priority. For example, a user story that can be completed quickly with minimal effort may be considered more important than a story that requires significant development effort.
4. Dependencies: User stories that have dependencies on other stories or features may be given higher priority to ensure that they are completed in the appropriate order.
5. Risks: User stories that address high-risk areas of the project or software may be given higher priority to mitigate potential issues.

The prioritization of user stories is usually done in collaboration with stakeholders, including product owners, end-users, and development team members. By considering these factors and working collaboratively, the team can ensure that they are delivering software that meets the needs of the end-users and achieves the project goals.

User Story – Acceptance Criteria Example and Template

User stories must be accompanied by acceptance criteria.  It is important to have descriptive summaries and detailed acceptance criteria to help the team know when a user story is considered complete or “done.” These are the conditions that the product must satisfy to be accepted by users, stakeholders, or a product owner. Each user story must have at least one acceptance criterion. Effective acceptance criteria are testable, concise, and clearly understood by all stakeholders. They can be written as checklists, plain text, or by using Given/When/Then format.

Example:

Here’s an example of the acceptance criteria checklist for a user story describing a search feature:

• A search field is available on the top-bar.
• A search is started when the user clicks Submit.
• The default placeholder is a grey text Type the name.
• The placeholder disappears when the user starts typing.
• The search language is English.
• The user can type no more than 200 symbols.
• It doesn’t support special symbols. If the user has typed a special symbol in the search input, it displays the warning message: Search input cannot contain special symbols.

Acceptance Criteria Formatted as Given-When-Then

According to the Agile Alliance, the Given-When-Then format is a template intended to guide the writing of acceptance criteria / tests for a User Story. The template is as follows:

(Given) some context
(When) some action is carried out
(Then) a particular set of observable consequences should obtain
An example:

Given my bank account is in credit, and I made no withdrawals recently,
When I attempt to withdraw an amount less than my card’s limit,
Then the withdrawal should complete without errors or warnings

The usual practice is the have the acceptance criteria written after the requirements have been specified and before development sprint begins. The acceptance criteria are often utilized during the user acceptance testing (UAT) of the product.

What are user story points?

User story points are a unit of measure used in agile software development to estimate the relative effort required to implement a user story. They are assigned to each user story based on the amount of effort and complexity involved in completing it, and help teams to prioritize and plan their work. Points are typically assigned using a scale such as Fibonacci numbers (1, 2, 3, 5, 8, 13, 21, etc.), where each number represents a larger increment of effort than the previous one. The purpose of using story points is to provide a rough, relative estimate of effort, rather than an exact estimate in terms of hours or days.

User story points are determined through a process called estimation. This is typically done as part of a team-based effort, with representatives from all relevant departments, such as development, testing, and product management.

Estimation is done by comparing each user story to others that have already been completed and assigned points, and by considering various factors that impact the effort required to implement the story, such as complexity, size, and uncertainty. The team then agrees on a point value for each story, usually using the Fibonacci scale. The way to think about estimating these points is similar to the way gap analysis is performed.

It’s important to note that the goal of user story points is to provide a rough, relative estimate of effort. The actual points assigned to each story are less important than the consistency in the way they are assigned and the fact that they allow the team to prioritize and plan their work. Over time, the team will gain a better understanding of what different point values represent and will become more accurate in their estimations.

If you’re using JIRA, then you see these points in the image as follows:

Become a business analyst with work experience

Techniques to estimate points and size user stories

There are several different techniques that can be used to size (estimate the effort required for) user stories in agile software development. Some of the most common techniques include:

1. Planning Poker: A consensus-based technique where team members hold cards with values from a predetermined scale (such as Fibonacci numbers) and simultaneously reveal their estimates for each story. Discussions ensue until the team reaches a consensus on the story’s point value.
2. T-Shirt Sizing: A quick and simple technique where team members use descriptive terms such as XS, S, M, L, XL, etc. to size stories, based on their complexity and effort required.
3. Affinity Mapping: A technique where team members write down their estimates for each story on sticky notes, and then group similar stories together based on their estimates. The resulting clusters of stories can then be assigned point values based on the average of the estimates within each cluster.
4. Expert Judgment: A technique where an individual with expertise in the relevant domain (e.g. a senior developer) provides estimates for each story based on their experience and knowledge.
5. Analogous Estimation: A technique where the team estimates the effort required for a new story based on similar stories that have been completed in the past, taking into account any differences or additional complexities.

These are some of the most common techniques used in agile software development to estimate the effort required for user stories. The choice of technique will depend on various factors such as the team’s experience, the size and complexity of the project, and the culture and preferences of the organization.

Steps to measure the team’s velocity with user story estimations

The velocity of an agile team is a measure of the amount of work the team can complete in a given period of time, usually a sprint. The velocity of a team can be determined by tracking the number of points completed in each sprint and taking an average over several sprints.

To determine the team’s velocity, follow these steps:

1. Assign story points to each user story: Use a sizing estimation technique, such as planning poker or T-shirt sizing, to estimate the effort required to complete each story.
2. Track completed story points in each sprint: At the end of each sprint, tally the number of points assigned to each story that was completed and accepted by the customer.
3. Calculate the average velocity: Divide the total number of completed story points by the number of sprints to calculate the average velocity. For example, if a team completed 40 story points in the first sprint and 50 story points in the second sprint, its average velocity would be 45 story points.
4. Use the velocity to plan future sprints: The team’s velocity can be used to plan future sprints, by taking into account the number of story points the team is capable of completing in a given sprint.

It’s important to note that the velocity of a team can change over time, based on various factors such as changes in team composition, the complexity of the work, and the team’s level of experience. As such, the velocity should be re-evaluated regularly to ensure that it accurately reflects the team’s current capabilities.

Become a business analyst with work experience

Elements of Agile Requirements

In addition to user stories, there are several other elements of agile requirements that are important to consider when developing software using agile methodologies. Some of these elements include:

• Epics: These are large-scale user stories that describe a high-level goal or feature. Epics are usually broken down into smaller user stories or tasks that can be completed in shorter iterations.
• Acceptance criteria: These are the specific conditions or requirements that must be met for a user story to be considered complete. Acceptance criteria are typically defined in collaboration with the product owner and the development team.
• User personas: These are fictional characters or archetypes that represent the different types of users who will be using the software system. User personas help the development team to understand the needs, goals, and behaviors of the end-users.
• Backlog: This is a prioritized list of user stories and tasks that need to be completed in the current iteration or sprint. The backlog is continuously updated and reprioritized based on feedback from the product owner, the development team, and other stakeholders.
• Iterations/sprints: These are short, time-boxed periods (usually 1-4 weeks) during which the development team works on a specific set of user stories and tasks. At the end of each iteration/sprint, the team delivers a working increment of the software system that can be reviewed and tested by stakeholders.

Frequently Asked Questions about Agile User Stories