how to write stories agile

Jira Software

Project and issue tracking

Content collaboration

Jira Service Management

High-velocity ITSM

Visual project management

• View all products

Marketplace

Connect thousands of apps and integrations for all your Atlassian products

Developer Experience Platform

Jira Product Discovery

Prioritization and roadmapping

You might find helpful

Cloud Product Roadmap

Atlassian Migration Program

Work Management

Manage projects and align goals across all teams to achieve deliverables

IT Service Management

Enable dev, IT ops, and business teams to deliver great service at high velocity

Agile & DevOps

Run a world-class agile software organization from discovery to delivery and operations

BY TEAM SIZE

Small Business

BY TEAM FUNCTION

Software Development

BY INDUSTRY

Telecommunications

Professional Services

What's new

Atlassian together.

Get Atlassian work management products in one convenient package for enterprise teams.

Atlassian Trust & Security

Customer Case Studies

Atlassian University

Atlassian Playbook

Product Documentation

Developer Resources

Atlassian Community

Atlassian Support

Enterprise Services

Partner Support

Purchasing & Licensing

Work Life Blog

Support for Server products ends February 15, 2024

With end of support for our Server products fast approaching, create a winning plan for your Cloud migration with the Atlassian Migration Program.

Assess my options

Atlassian Presents: Unleash

Product updates, hands-on training, and technical demos – catch all that and more at our biggest agile & DevOps event.

Register now

• Atlassian.com
• Agile project management
• User Stories

User stories with examples and a template

User stories are development tasks often expressed as “persona + need + purpose.” 

Browse topics

Summary:  A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.

It's tempting to think that user stories are, simply put, software system requirements. But they're not. 

A key component of agile software development is putting people first, and a user story puts end users at the center of the conversation. These stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building, what they're building, and what value it creates. 

User stories are one of the core components of an agile program. They help provide a user-focused framework for daily work — which drives collaboration, creativity, and a better product overall.

What are agile user stories?

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.

A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer. 

The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.

User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.

Stories fit neatly into agile frameworks like scrum and kanban . In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. These larger structures ensure that the day-to-day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.

Learn more about epics and initiatives

Why create user stories?

For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project ( the epic ) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.

User stories serve a number of key benefits:

• Stories keep the focus on the user. A to-do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.  
• Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.  
• Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.  
• Stories create momentum.  With each passing story, the development team enjoys a small challenge and a small win, driving momentum.  

See how user stories work in Jira Software

Working with user stories

Once a story has been written, it’s time to integrate it into your workflow. Generally a story is written by the product owner, product manager, or program manager and submitted for review.

During a sprint or iteration planning meeting, the team decides what stories they’ll tackle that sprint. Teams now discuss the requirements and functionality that each user story requires. This is an opportunity to get technical and creative in the team’s implementation of the story. Once agreed upon, these requirements are added to the story.

Another common step in this meeting is to score the stories based on their complexity or time to completion. Teams use t-shirt sizes, the Fibonacci sequence, or planning poker to make proper estimations. A story should be sized to complete in one sprint, so as the team specs each story, they make sure to break up stories that will go over that completion horizon.  

How to write user stories

Consider the following when writing user stories:

• Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.  
• Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.  
• User personas — For whom? If there are multiple end users, consider making multiple stories.  
• Ordered Steps — Write a story for each step in a larger process.  
• Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.  
• Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.  

Once the user stories are clearly defined, make sure they are visible for the entire team.

User story template and examples

User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”

Breaking this down: 

• "As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.
• “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point.
• “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

For example, user stories might look like:

• As Max, I want to invite my friends, so we can enjoy this service together.
• As Sascha, I want to organize my work, so I can feel more in control. 
• As a manager, I want to be able to understand my colleagues progress, so I can better report our sucess and failures. 

This structure is not required, but it is helpful for defining done. When that persona can capture their desired value, then the story is complete. We encourage teams to define their own structure, and then to stick to it.

Getting started with agile user stories

User stories describe the why and the what behind the day-to-day work of development team members, often expressed as persona + need + purpose . Understanding their role as the source of truth for what your team is delivering, but also why, is key to a smooth process.

Start by evaluating the next, or most pressing, large project (e.g. an epic). Break it down into smaller user stories, and work with the development team for refinement. Once your stories are out in the wild where the whole team can see them, you’re ready to get to work.

As a self-proclaimed “chaos muppet” I look to agile practices and lean principles to bring order to my everyday. It’s a joy of mine to share these lessons with others through the many articles, talks, and videos I make for Atlassian 

How to create user stories in Jira Software

Discover how teams can use issues to track individual pieces of work that must be completed.

What are story points and how do you estimate them?

An inside look into secrets of agile estimation and story points. Good agile estimation lets product owners optimize for efficiency and impact.

Stories act as a ‘pidgin language,’ where both sides (users and developers) can agree enough to work together effectively. —Bill Wake, co-inventor of Extreme Programming

Stories are short descriptions of a small piece of desired functionality written from the user’s perspective.

Stories are the primary artifact used to define system behavior in Agile. They are short, simple descriptions of functionality told from the user’s perspective and written in their language. Each implements a small, vertical slice of system behavior.

Stories provide just enough information for business and technical people to understand the intent. Details are deferred until the story is ready to be implemented. Through acceptance criteria and acceptance tests, stories get more specific, helping to ensure system quality.

User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.

SAFe describes a four-tier hierarchy of artifacts that outline functional system behavior: Epic , Capability , Feature , and Story. Collectively, these artifacts are used to describe the solution’s intended behavior. The detailed implementation work is expressed through stories, which comprise the Team Backlog . Some stories emerge from business and enabler features in the ART Backlog , while others come from the team’s local context.

Each story is a small, independent behavior that can be implemented incrementally and provides some value to the user or the Solution . It’s a vertical slice of functionality to ensure that every Iteration delivers new value. Stories are small and must be completed in a single iteration (see the splitting stories section).

Often, stories are first written on an index card or sticky note. The physical nature of the card creates a tangible relationship between the team, the story, and the user: it helps engage the entire team in story writing. Sticky notes also offer other benefits: they help visualize work and can be readily placed on a wall or table, rearranged in sequence, and even passed off when necessary. Stories allow an improved understanding of the scope and progress:

• “Wow, look at all these stories we are about to sign up for” (scope)
• “Look at all the stories we accomplished in this iteration” (progress)

While anyone can write stories, approving them into the team backlog and accepting them into the system baseline are the Product Owner’s responsibility. Of course, stickies don’t scale well across the Enterprise , so stories often move quickly into Agile Lifecycle Management (ALM) tooling.

There are two types of stories in SAFe, user stories and enabler stories, as described below.

Sources of Stories

Stories are typically driven by splitting business and enabler features, as Figure 1 illustrates.

User Stories

User stories are the primary means of expressing needed functionality. They essentially replace the traditional requirements specification. In some cases, however, they serve as a means to explain and develop system behavior later recorded in specifications supporting compliance, suppliers, traceability, or other needs.

Because they focus on the user as the subject of interest and not the system, user stories are value and customer-centric. To support this, the recommended form of expression is the ‘user-voice form,’ as follows:

As a (user role), I want to (activity) so that (business value)

By using this format, the teams are guided to understand who is using the system, what they are doing with it, and why they are doing it. Applying the ‘user voice’ format routinely tends to increase the team’s domain competence; they come to better understand the real business needs of their user. Figure 2 provides an example.

As described in Design Thinking , personas describe specific characteristics of representative users that help teams better understand their end user. Example personas for the rider in Figure 2 could be a thrill-seeker ‘Jane’ and a timid rider ‘Bob.’ Stories descriptions can then reference these personas (As Jane I want…).

While the user story voice is typical, not every system interacts with an end user. Sometimes the ‘user’ is a device (for example, printer) or a system (for example, transaction server). In these cases, the story can take on the form illustrated in Figure 3.

Enabler Stories

Teams also develop the new architecture and infrastructure needed to implement new user stories. In this case, the story may not directly touch any end user. Teams use ‘enabler stories’ to support exploration, architecture, or infrastructure. Enabler stories can be expressed in technical rather than user-centric language, as Figure 4 illustrates.

There are many other types of Enabler stories, including:

• Refactoring  and Spikes (as traditionally defined in XP)
• Building or improving development/deployment infrastructure
• Running jobs that require human interaction (for example, indexing 1 million web pages)
• Creating the required product or component configurations for different purposes
• Verification of system qualities (for example, performance and vulnerability testing)

Enabler stories are demonstrated just like user stories, typically by showing the knowledge gained, artifacts produced, or the user interface, stub, or mock-up.

Writing Good Stories

Good stories require multiple perspectives. In Agile, the entire team creates a shared understanding of what to build to reduce rework and increase throughput. Teams collaborate using Behavior-Driven Development (BDD) to define detailed acceptance tests that definitively describe each story.

Collaborative story writing ensures all perspectives are addressed, and everyone agrees on the story’s behavior with the results represented in the story’s description, acceptance criteria, and acceptance tests. The acceptance tests are written using the system’s domain language using BDD. BDD tests are then automated and run continuously to maintain Built-In Quality. The BDD tests are written against system requirements (stories) and, therefore, can be used as the definitive statement for the system’s behavior, replacing document-based specifications.

The 3Cs: Card, Conversation, Confirmation

Ron Jeffries, one of the inventors of XP, is credited with describing the 3Cs of a story:

• Card – Captures the user story’s statement of intent using an index card, sticky note, or tool. Index cards provide a physical relationship between the team and the story. The card size physically limits story length and premature suggestions for the specificity of system behavior. Cards also help the team ‘feel’ upcoming scope, as there is something materially different about holding ten cards in one’s hand versus looking at ten lines on a spreadsheet.
• Backlog refinement
• Implementation

These just-in-time discussions create a shared understanding of the scope that formal documentation cannot provide. Specification by example replaces detailed documentation. Conversations also help uncover gaps in user scenarios and NFRs.

• Confirmation – The acceptance criteria provide the information needed to ensure that the story is implemented correctly and covers the relevant functional and NFRs. Figure 5 provides an example. Some teams often use the confirmation section of the story card to write down what they will demo.

Agile Teams automate acceptance tests wherever possible, often in business-readable, domain-specific language. Automation creates an executable specification to validate and verify the solution. Automation also provides the ability to quickly regression-test the system, enhancing Continuous Integration , refactoring, and maintenance.

Investing in Good Stories

Agile teams spend significant time discovering, elaborating, and understanding user stories and writing acceptance tests. This is as it should be, because it represents the fact that:

Writing the code for an understood objective is not necessarily the most challenging part of software development.

Instead, it is understanding the real objective of the code. Therefore, investing in good user stories, albeit at the last responsible moment, is a worthy effort for the team. Bill Wake coined the acronym INVEST [1] to describe the attributes of a good user story.

•  I – Independent (among other stories)
• N – Negotiable (a flexible statement of intent, not a contract)
• V – Valuable (providing a valuable vertical slice to the customer)
• E – Estimable (small and negotiable)
• S – Small (fits within an iteration)
• T – Testable (understood enough to know how to test it)

Splitting Good Stories

Smaller stories allow faster, more reliable implementation since small items flow through any system faster, with less variability and reduced risk. Therefore, splitting bigger stories into smaller ones is a mandatory skill for every Agile team. It’s both the art and the science of incremental development. Agile Software Requirements describes ten ways to split stories [1]. A summary of these techniques follows:

• Workflow steps
• Business rule variations
• Major effort
• Simple/complex
• Variations in data
• Data entry methods
• Deferred system qualities
• Operations (ex., Create, Read, Update, Delete [CRUD])
• Use-case scenarios
• Break-out spike

Figure 6 illustrates an example of splitting by use-case scenarios.

Estimating Stories

Agile teams use story points and ‘estimating poker’ to value their work [1, 2]. A story point is a singular number that represents a combination of qualities:

• Volume – How much is there?
• Complexity – How hard is it?
• Knowledge – What’s known?
• Uncertainty – What’s unknown?

Story points are relative, without a connection to any specific unit of measure. Each story’s size (effort) is estimated relative to the smallest story, which is assigned a size of ‘one.’ A modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) [2] is applied that reflects the inherent uncertainty in estimating, especially large numbers (for example, 20, 40, 100).

Estimating Poker

Agile teams often use ‘ estimating poker ,’ which combines expert opinion, analogy, and disaggregation to create quick but reliable estimates. Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces.

(Note that there are several other methods used as well.) The rules of estimating poker are:

• Participants include all team members
• Each estimator is given a deck of cards containing the modified Fibonacci sequence
• The PO participates but does not estimate
• The Scrum Master/Team Coach participates but does not estimate unless they are doing actual development work
• For each backlog item to be estimated, the PO reads the story’s description
• Questions are asked and answered
• Each estimator privately selects an estimating card representing their estimate
• All cards are turned over at the same time to avoid bias and to make all estimates visible
• High and low estimators explain their estimates
• After a discussion, each estimator re-estimates by selecting a card
• The estimates will likely converge; if not, the process is repeated

Some amount of preliminary design discussion is appropriate. However, spending too much time on design discussions is often a wasted effort. The real value of estimating poker is agreeing on a story’s scope. It’s also fun!

The team’s velocity for an iteration is equal to the sum of the points for all the completed stories that met their definition of done (DoD). As the team works together over time, their average velocity (completed story points per iteration) becomes reliable and predictable. Predictable velocity assists with planning and helps limit Work in Process (WIP), as teams don’t take on more stories than their historical velocity would allow. This measure also estimates how long it takes to deliver epics, features, capabilities, and enablers, which are also forecasted using story points.

Capacity is the portion of the team’s velocity that is available for any given iteration. Vacations, training, and other events can make team members unavailable to contribute to an iteration’s goals for some portion of the iteration. This decreases the maximum potential velocity for that team for that iteration. For example, a team that averages 40 points delivered per iteration would adjust their maximum velocity down to 36 if a team member is on vacation for one week. Knowing this in advance, the team only commits to a maximum of 36 story points during iteration planning. This also helps during PI Planning to forecast the actual available capacity for each iteration in the PI, so the team doesn’t over-commit when building their PI Objectives.

Starting Baseline for Estimation

In standard Scrum, each team’s story point estimating—and the resulting velocity—is a local and independent concern. At scale, it becomes difficult to predict the story point size for larger epics and features when team velocities vary wildly. To overcome this, SAFe teams initially calibrate a starting story point baseline where one story point is defined roughly the same across all teams. There is no need to recalibrate team estimation or velocity. Calibration is performed one time when launching new Agile Release Trains .

Normalized story points provide a method for getting to an agreed starting baseline for stories and velocity as follows:

• Give every developer-tester on the team eight points for a two-week iteration (one point for each ideal workday, subtracting two days for general overhead).
• Subtract one point for every team member’s vacation day and holiday.
• Find a small story that would take about a half-day to code and a half-day to test and validate. Call it a ‘one.’
• Estimate every other story relative to that ‘one.’

Example : Assuming a six-person team composed of three developers, two testers, and one PO, with no vacations or holidays, then the estimated initial velocity = 5 × 8 points = 40 points/iteration. (Note: Adjusting slightly lower may be necessary if one of the developers and testers is also the Scrum Master/Team Coach.)

In this way, story points are somewhat comparable across teams. Management can better understand the cost for a story point and more accurately determine the cost of an upcoming feature or epic.

While teams will tend to increase their velocity over time—and that’s a good thing— in reality, the number tends to remain stable. A team’s velocity is far more affected by changing team size and technical context than by productivity variations.

SAFe Kanban teams may initially use estimating poker or a similar mechanism to size their stories. More likely, however, they develop a sense of breaking work into stories that are similar in size, as that assists flow in general and assures that no large story blocks other stories that also need to make their way through the Kanban system. As they understand their velocity, they are able to understand how many stories they can deliver in a unit of time, allowing them to place stories in iterations during PI Planning and to be able to make commitments to other teams as to when specific stories would be available.

For teams doing regular maintenance and support activities, estimating their normal backlog items often has less value. In many cases, these teams do not estimate this type of response work. However, all teams have retro items, potential improvements to their CD pipeline, and other significant tasks that require attention, scheduling, and estimating.

Last update: 7 December 2022

Privacy Overview

The Anatomy of a User Story

User stories are an enigma. While quite possibly the simplest way to identify the work to be done by an agile team, they remain, after 25 years, misunderstood and misused. In this blog post, I want to break user stories down to the basics and make it so that you can benefit from user stories as you should.

User stories should be simple, concise statements of problems to be solved. They are not requirements documents, nor are they design docs -- they are not documents at all. Or, as Ron Jefferies put it, "a user story is meant to be a placeholder for a conversation about the work to be done." Ron succinctly described user stories in terms of the 3Cs - card, conversation, confirmation. "Card" is a reminder to keep your stories short. "Conversation" is a reminder that the story doesn't transmit everything in the context; most of the understanding of a user story comes from conversations between stakeholders and scrum teams . Finally, "confirmation" is a reminder that user stories should give you insight into what should be true when the problem the story describes is solved.

Rachel Davies made this really easy in her now famous "As a < role >, I want < action >, so that < value or justification >" template from 2002. In Rachel's format for a user story, "confirmation" is contained in the "so that" clause.

It's important to understand that while Rachel Davies' story format is best practice, it isn't the ONLY practice. Write user stories any way that you like. Rachel's approach is simply one of the best ways. So, in short, there is NO REQUIRED STRUCTURE for a user story. What's important is that you capture the following:

• Who is the user? (Stakeholder, persona, role)
• What do they want to do? (Action)
• Why do they want to do it? (Value or Justification)

Anything else is simply fluff and can be left out. Add additional thoughts to notes about the backlog item; attach documents and drawings as you learn more, but the basic user story should be straightforward.

Now that we've discussed the basics of user stories, let's move on to how to write effective user stories.

It's About the Problem, Not the Solution

The biggest mistake I see with how people write user stories is writing them as requirements. In other words, the following might look like a good user story:

"As a college registrar, I want to be able to search for a student when a family member calls."

But does this make much sense? For example, what if the original conversation with the registrar sounded more like this:

"As a college registrar, I want to be able to connect a family member and a student quickly in the event of an emergency so that I don't have to search for the student while the family member gets more and more upset while waiting on the phone."

It's been my experience over the years that stakeholders are REALLY GOOD at identifying their problems but are REALLY BAD at knowing the right solution (even when they think they know the right solution already).

Include Performance Expectations

Keep your user stories simple, but don’t shy away from simple extensions to the fundamental structure to include additional useful information. For example, what if the registrar from the previous example said they needed to make the connection within two minutes (as, according to their experience, callers in an emergency tend to get abusive after two minutes)? So, why not add that to the user story?

"As a college registrar, I want to be able to connect a family member and a student quickly in the event of an emergency within two minutes so that I don't have to search for the student while the family member gets more and more upset while waiting on the phone."

See how easy that was? We added a simple performance expectation to the user story. The developers will know that part of the story is about speed and performance. They can factor that into their development plans.

What if the Stakeholder is Already Doing Something Less Effective?

Sometimes user stories are problems that need better, alternative solutions. The customer is already doing something but is having trouble getting the job done. You need the developers to understand what the stakeholder wants to STOP and the problem that needs solving. Extend the user story structure:

"As a college registrar, instead of having to make a bunch of separate phone calls trying to track down the student, I want to be able to connect a family member and a student quickly in the event of an emergency within two minutes so that I don't have to search for the student while the family member gets more and more upset while waiting on the phone."

A Complete Template

In my online training program, Amazing Stories! , I provide the following template. 

AS A {user|persona|system},

[INSTEAD OF {current condition}]

I WANT TO {action} [IN {mode} TIME | IN {differentiating performance units} TO {utility performance units}

[SO THAT {value or justification}]

[NO LATER THAN {best by date}]

Please try using this template the next time you’re creating user stories. 

Want to stay informed on the latest scrum and agile stories? Please subscribe to stay updated. Explore Scrum Alliance certifications to discover a path that may be right for your goals.

Get the latest resources from Scrum Alliance delivered straight to your inbox

• United States
• United Kingdom

How to write agile user stories: 7 guidelines

Beyond the basics: how to provide agile user stories more definition and structure to ensure there is a shared understanding of the intent and underlying requirements.

Contributor, InfoWorld |

Fundamentally, agile user stories are short, simple tools to document a single action or intention desired by the targeted user to achieve a goal. The simplest user stories have a format, “As a user type or role , I want to action or intent  so that reason or benefit ” that answers at least three simple questions on who, what, and why the story is in the backlog queue.

As teams mature and organizations use agile across multiple teams and initiatives, agile user stories often take on a lot more definition and structure to ensure there is a shared understanding of the intent and underlying requirements.

Getting started with writing agile user stories

There are plenty of resources to help new product owners, business analysts, scrum masters, and technical leads to understand the basics of writing user stories. Some places to start include articles from Atlassian ,  FreeCodeCamp , Agile Modeling , and these 200 user story examples . One of the more complete writeups is in Alexander Cowan’s best agile user story . There are books on story writing, including User Story Mapping   by Jeff Paton and Peter Economy and User Stories Applied   by Mike Cohn. You can also take courses on story writing from Udemy ,  Learning Tree , VersionOne , and Lynda .

One fundamental principle first shared by Bill Wake is to invest in good stories . Invest  stands for “independent, negotiable, valuable, estimable, small, and testable,” which make a good checklist for agile story writers. “ An agile leader’s guide to writing user stories ” is one article that explains how to apply invest  principles.

The basics are relatively easy, yet I often hear and witness disconnects among stakeholders, product owners, developers, and testers around the quality of the requirements or whether a story is truly done. There are sometimes conflicting viewpoints on the level of detail required, where to fit in technical requirements, and what artifacts should be created with user stories.

With these questions in mind, here are seven beyond-the-basics guidelines on writing agile user stories.

1. Write stories for the audiences that will use them

Before writing stories, keep in mind that stories are meant to be read and understood by people participating in the development process with different needs and responsibilities. Story writers and contributors should keep the audience in mind and draft stories to address the collective needs:

• Product owners may not be the ones writing the stories, especially if your organization delegates this function to business analysts or if there are multiple people involved in story writing. Product owners want to make sure that the story fully captures the user needs and intent. They should read through the detailed acceptance criteria but don’t necessarily want to be bogged down with technical implementation details. Product owners should also understand how the story is aligned to the bigger picture, so they must take an active interest in how epics and features are defined and how stories are assigned to them.
• Stakeholders will not read the story details but will drill down from epics and read the story summary. If you have many stakeholders, consider using a descriptive format for summaries and moving the “As a user type or role ” description to the start of the user story description.
• Technical leads are often the first person from the team to review stories, and they will study the requirements to see if a story is too big and should be split into multiple stories, or see if the story needs some upfront technical work to determine the best solution.
• The assignee is the individual responsible to review the details and report on progress at daily standup meetings. Assignees should be reviewing stories for dependencies that may become blocks during the sprint.
• Team members often review all stories to understand their assigned stories in the context of other stories assigned to the sprint.
• Testers determine if there are gaps or risks not identified in the acceptance criteria and then consider how best to implement them in automated testing frameworks.
• The team’s analyst, who may be a program manager or a member of the project management office, want stories fully labeled and categorized so that meaningful metrics can be pulled from the backlog.

2. Start with the user in mind

Although agile user stories may require many details, it’s very important to start with the user in mind. The story should be defining what  action or intent the user wants to accomplish and why  this addresses a need, a core value, or a goal derived from the experience.

For more complex applications, defining different user personas that illustrate needs, values, and usage patterns of different user types is an important discipline and can enhance story writing. In “ 10 tips for writing good user stories ,” Roman Pichler suggests that “the persona goals help you discover the right stories. Ask yourself what functionality the product should provide to meet the goals of the personas.” Using personas to reinforce user goals provides a richer meaning of why a story is important and aids in prioritizing the backlog.

3. Answer why the story is important

Understanding, documenting, and discussing user needs or user persona goals is just one dimension around why the product owner is prioritizing stories. The story should also provide business value, something that is hard to quantify but may be qualifiable  at the story, feature, epic, or release level.  

Answering why  can be important for the developers when they’re empowered to propose different implementation options. For example, a feature that improves the login experience for users may also benefit the business if the new experience also generates better customer data. A developer can reflect on this added business value and optimize the implementation for this goal even if the story’s acceptance criteria isn’t specific about this requirement.

4. Define acceptance criteria without prescribing a solution

The most significant discipline to focus on in story writing is in drafting acceptance criteria. These are often bulleted lists of short pass-or -fail statements that document requirements, constraints, metrics, and expectations. These acceptance criteria are often used in several ways:

• Technical leads and teams use them to estimate story points based on complexity and effort .
• Developers narrow down the implementation options to ones that meet acceptance criteria.
• Product owners may reduce scope or complexity of acceptance criteria to drive implementations with lower estimates.
• The assignee communicates blocks or issues meeting difficult criteria during standups.
• Quality assurance engineers use acceptance criteria to develop automated tests.
• The product owner reviews key criteria during the agile demo to ensure the story is done .

Writing acceptance criteria isn’t trivial. Acceptance criteria for acceptance criteria highlight some of the issues such as providing too many criteria, defining criteria that are too vague, or documenting complex criteria that can’t easily be verified. Some writers use acceptance criteria templates that define a structure for short, atomic, and testable criteria.

5. Use stories to define what and why; define tasks on how to implement

One of the critical mistakes I see teams make around story writing is to be verbose and specific around the implementation. These poorly written stories invest a lot of effort on describing how to implement often at the expense of describing what the user needs, why  it addresses their goals, and where  it drives business value.

There are a few reasons this might happen.

Inexperienced product owners may use stories to paint their implementation visions. In other words, they may be overly specifying user design and functional implementations instead of sharing the target user experience and benefits. Some product owners confuse their conceptualization of how something might  work (the process by which they come to understand the requirements) with how it should  work, accidentally turning an internal implementation example into an external implementation specification.

Other product owners may overstep their bounds by asking the team to “build me this.” That is one of my 20 bad behaviors of product owners , for which I have recommendations to product owners on collaborating with the team around solutions .

The other reason that stories may become cluttered with implementation details is that some teams and tech leads want this level of detail. Newly formed technical teams working to enhance existing applications may desire this level of detail until they better understand how the application works and fully comprehend user needs. Some distributed teams working with offshore developers or freelancers may also want to document the implementation details to ensure these members understand their responsibilities.

For such teams, the best thing to do is to link to implementation diagrams and document who is doing what and how as tasks linked to the story. Most agile management tools allow tasks or subtasks, and this level of detail is usually separated from the body of the story. A diagram in this post does a good job illustrating this important principle of using agile stories to break down user experiences and business processes and adding in tasks to define the implementation to individual pieces of work.

6. Tag your stories to drive analytics and practice improvements

Once stories are written, worked on, and completed, many teams look to capture metrics and perform analytics that can drive process improvement or used to make business cases for added investment.

Here are some examples:

• Label stories as technical debt to quantify the size of the debt, the percent of the team’s velocity used to address it, and the total debt completed with every release.
• Define functional and technical spike stories to drive experimentation and innovation, then report on where it’s having business impact.
• If your team is estimating agile user stories , ask the team to tag stories at the end of the sprint to signal whether they overestimated or underestimated to improve the accuracy of estimations.
• Use labels, components, and custom fields to aid searching the backlog for historical understandings or metrics. For example, knowing what stories impacted the APIs or what requirements led to the last functional improvements to a specific area of the application can be done when stories are tagged to functional and technical components.
• Tag stories collecting or processing sensitive information such as personally identifiable information (PII), e-commerce transactions, or industry regulated data such as HIPAA data to enable security and compliance reviews.
• Provide feedback to the product owner and team. Beyond marking a story done , a product owner could also provide feedback to the team such as acknowledging a great job . Similarly, the team can provide feedback to the product owner on the overall quality and interpretability of a user story.

7. Define agile story templates and style guides

Larger organizations working with multiple agile teams and product owners may want to draft standards and style guides for story writing. The consistency helps new product owners learn the writing skills faster and also improves team members efficiency in consuming the information.

Another reason to design story templates is that different types of products and applications lend themselves to different user story expressions and artifacts. Some examples:

• Business process stories may require links to workflow diagrams and also specify roles and permissions.
• Customer-facing applications stories should have links to wireframes and include performance criteria.
• API stories should document expected usage patterns and metrics.
• Business intelligence and data visualization stories should provide guidelines around what fields and information is needed for the requested analysis.

Templates help bridges the communication between teams and product owners on what to focus on when writing agile stories.

And isn’t that the point of agile stories? Agile story writing practices, guidelines, and principles are there to help teams know what’s important for users and for the business before considering how to implement.

Next read this:

• The best open source software of 2023
• Do programming certifications still matter?
• Cloud computing is no longer a slam dunk
• What is generative AI? Artificial intelligence that creates
• Coding with AI: Tips and best practices from developers
• Why Wasm is the future of cloud computing
• Agile Development
• Software Development

Isaac Sacolick is president of StarCIO and the author of the Amazon bestseller Driving Digital: The Leader’s Guide to Business Transformation through Technology and Digital Trailblazer: Essential Lessons to Jumpstart Transformation and Accelerate Your Technology Leadership . He covers agile planning , devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO and digital transformation influencer. He has published more than 900 articles at InfoWorld.com , CIO.com , his blog Social, Agile, and Transformation , and other sites.

Copyright © 2019 IDG Communications, Inc.

Search the site:

Browse topics

Browse these topics:

• User Stories

User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. Every agile user story includes a written sentence or two and, more importantly, sparks a series of conversations about the features and functionality the user story represents.

User stories are a way to describe the desired functionality of product backlog items. High-priority user stories tend to be more detailed; low-priority user stories tend to be less detailed. Teams add details as stories rise in priority, either by creating acceptance criteria or by splitting big stories into smaller pieces (or both). Read on to discover more about user stories and the user story template, and to see some examples of user stories.

Get 200 Real Life User Stories Examples Written by Mike Cohn

See user stories Mike Cohn wrote as part of several real product backlogs.

Email Address

We hate spam and promise to keep your email address safe. Unsubscribe at any time. Privacy Policy

Learn About Agile

• An Introduction to Agile and Scrum
• The Scrum Framework
• Agile Planning
• Estimating with Story Points
• Planning Poker
• Agile Software Development
• Agile Project Management

What is a user story?

A user story is a  short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories typically follow a simple template :

As a , I want so that .

Historically user stories were deliberately kept informal, written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. Their impermanence made it easy to tear them up,  throw them away, and replace them with new stories as more was learned about the product being developed.

Nowadays, user stories might just as easily be stored in a Jira issue or Trello board. Don't let the fact that a user story exists in a tool make you any less willing to discard stories when they are no longer needed!

User stories are designed to strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

What Is a Good User Story?

Agile user stories are composed of three aspects that Ron Jeffries named in 2001 with the wonderful alliteration of card, conversation, and confirmation:

• Card : Written description of the story, used for planning and as a reminder
• Conversation : Conversations about the story that serve to flesh out the details of the story
• Confirmation : Tests that convey and document details that can be used to determine when a story is complete.

User stories have many advantages , but the most important might be that every user story is a placeholder for a future conversation.

How to write a user story

Writing good user stories in Scrum requires an understanding of the basic user story template, a focus on the user or customer, and a clear picture of the desired functionality.

User Story Template

When writing a user story, remember that user stories follow a standard template: As a < type of user >, I want < some goal > so that < some reason >.

Examples of User Stories

One of the best ways to learn how to write a user story in agile is to see examples. Below is an example user story or two. These are a few real examples of user stories that describe the desired functionality in an early version of the Scrum Alliance website. 

• As a site member, I can fill out an application to become a Certified Scrum Trainer so that I can teach Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) courses and certify others.
• As a trainer, I want my profile to list my upcoming classes and include a link to a detailed page about each so that prospective attendees can find my courses.
• As a site visitor, I can access old news that is no longer on the home page, so I can access things I remember from the past or that others mention to me.
• As a site visitor, I can see a list of all upcoming “Certification Courses” and can page through them if there are a lot, so I can choose the best course for me.

Note that you don't see any user story, "As a product owner, I want a list of certification courses so that..." The product owner is an essential stakeholder, but is not the end user/customer. When creating user stories, it's best to be as specific as possible about the type of user. 

200 User Stories Examples

Who writes user stories?

Does the product owner write user stories?

It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user stories written by each team member.

Also, note that who writes a user story is far less important than who is involved in the discussions of it.

When are user stories written?

User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.

Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.

Can you show other user story examples?

As a more generic example of writing user stories in Scrum, these are some typical user stories for a job posting and search site:

• A user can post her resume to the web site.
• A user can search for jobs.
• A company can post new job openings.
• A user can limit who can see her résumé.

Examples of Epics 

One of the benefits of agile user stories is that they can be written at varying levels of detail . We can write a user story to cover large amounts of functionality or only a small distinct feature. 

Large user stories are less detailed, and are generally known as epics .

Here is an epic agile user story example from a desktop backup product:

• As a user, I can backup my entire hard drive.

Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two example user stories:

• As a power user, I can specify files or folders to backup based on file size, date created and date modified.
• As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

How is detail added to user stories?

Detail can be added to user stories in two ways:

• By splitting a user story into multiple, smaller user stories.
• By adding conditions of satisfaction (acceptance criteria).

When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that detail has been added. After all, more has been written.

The conditions of satisfaction is simply a high-level acceptance test that will be true after the agile user story is complete. Consider the following as another agile user story example:

As a vice president of marketing, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones.

Detail could be added to that user story example by adding the following conditions of satisfaction:

• Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
• Support holidays that span two calendar years (none span three).
• Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
• Holiday seasons can be set to be a number of days prior to the holiday.

Do user stories replace a requirements document?

Agile projects , especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.

It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.

Recommended Resources

Non-functional Requirements as User Stories

Advantages of User Stories over Requirements and Use Cases

Introduction to User Stories

A Sample Format for a Spreadsheet-Based Product Backlog

Related courses.

• See all teams
• See all use cases
• See all integrations
• See all features
• Help Center
• Wrike's Community
• Training & Certifications
• Facilitated Services
• Premium Support
• Submit a Ticket

How to Create User Stories

• 1.  What Is the Agile Manifesto?
• 2.  The Benefits and Advantages of Agile
• 3.  What Is Agile Operations?
• 4.  The Agile Software Development Life Cycle
• 5.  Building an Agile Team Structure
• 6.  A Guide to the Scaled Agile Framework (SAFe)
• 7.  Agile and Lean Portfolio Management
• 8.  Understanding Squads, Tribes, and Guilds
• 9.  What Is Agile Transformation?
• 10.  Themes, Epics, Stories, and Tasks in Agile
• 11.  A Complete Guide to Agile Epics

What is a user story?

User story examples, five steps for writing user stories, what makes a good user story, benefits of user stories, disadvantages of user stories.

• 13.  Agile Estimation: Understanding Story Points
• 14.  Using Gantt Charts in Agile
• 15.  Glossary
• 16.  FAQs

“The customer is always right.” Though this motto is often contested in the retail world, it’s not a bad one to keep in mind for Agile projects. In fact, customer satisfaction is listed as the highest priority in the  Agile Manifesto .

In Agile methodology, it is common practice to include user feedback in the development process. Agile teams welcome this external perspective to ensure they are on the right track and that the final deliverable will suit the customer’s needs.

When breaking projects down into an  Agile work structure , teams will start by exploring the customer perspective. This is usually done by creating user stories.

In this article, we will talk all about user stories - what they are, how to write one, the benefits, and the disadvantages. We’ll also share an  Agile project plan template  to help you manage your Agile projects from end to end.

If you would like to unlock the power of using robust software for your Agile projects and streamline all of your Agile workflows in one place, you can sign up for a free trial with Wrike today.

A user story is a small unit of work in an  Agile workflow . It is a short, written explanation of a particular user’s need and how it can be fulfilled. There is no room for jargon in a user story. It is written in easily accessible language to provide a clear picture of what the user requires. The technical details can be discussed at a later stage.

Every user story involves a short-form request that is completed in one  Agile iteration  or  sprint , which normally lasts about one or two weeks. Teams measure the complexity of their user stories with  story points , helping them to accurately estimate how long a particular request will take.

A collection of Agile user stories is referred to as an  epic . A product owner will be responsible for managing the epic, but they can be written by any Agile team member.

A user story is similar to a use case but is not as detailed. The former is a very brief description of a planned action item, while the latter will likely contain extra sections such as required conditions, various paths a user might take in using a product, and workflow diagrams.

Seamlessly execute all your Agile projects

In the Agile framework, user stories follow a simple template. The chosen user story format will outline the “who,” “what,” and “why” of a particular requirement.

• Who wants something?
• What do they want?
• Why do they want it?

The following template is one of the most common:

“As [persona], I want to [action], so that I can [benefit].”

For each story, the writer will include a user persona, the action they wish to take or the ability they wish to have, and the benefit they hope to achieve as a result. Here are some examples:

Example 1: An online gamer

“As an online gamer, I want to have a multiplayer option so that I can play online with friends.”

Example 2: A design team lead

“As a design team lead, I want to organize assets, so I can keep track of multiple creative projects.”

Example 3: An e-commerce shopper

“As an e-commerce shopper, I want to filter my searches so I can find products quickly.”

Now that you know what a user story looks like, you can get to work creating one.

Want some practical advice on how to write user stories? Use these five steps as a guide:

Step 1: Outline acceptance criteria

The  definition of done  is the set of criteria that needs to be fulfilled for your user story to be considered complete. Define the specific acceptance criteria and use it as a checklist.

Step 2: Decide on user personas

Conduct extensive user research by creating surveys, hosting focus groups, and reading user forums. Analyze your data and search for patterns to identify your key personas .

Step 3: Create tasks

Break your story down into numerous  tasks  to make it more manageable. If it is a complex requirement, you can also add subtasks. Include detailed descriptions, so your team is aligned on what each task requires.

Step 4: Map stories 

Use  user story mapping  to structure work in a large process. In this case, your stories will take the form of ordered steps.

Step 5: Request feedback

Speak to users and potential customers to find out what they want. Ask them for their opinions on existing products or if they have suggestions for new features. Incorporate this feedback into your user story.

So, you’ve written your user story. But how do you know if it’s any good?

Agile teams assess the quality of stories by using the INVEST acronym . This stands for:

• I ndependent: The user story should be independent of all others. Because they are not connected, they can be worked on in any order.
• N egotiable: A user story should be flexible enough to allow for negotiation between the customer and product owner.
• V aluable: What value does the user story bring? If you cannot find any value, the story should not be completed.
• E stimable: You should be able to estimate how long a user story will take so that you can effectively manage your time.
• S mall: The story must be small enough to be completed within a single sprint.
• T estable: You must be able to test your user story in line with quality assurance standards.

If a user story does not meet the INVEST criteria, it should be rewritten or removed from the epic. However, if it does, your team members can get to work. Schedule daily Agile meetings to check on their progress and ensure they are on track to complete the user story within the sprint timeframe .

Why write user stories in the first place? Because they offer numerous benefits for an Agile project. Here are a few examples:

• Simplified format: User stories are written in easy-to-understand language. This eliminates confusion and makes it easier to grasp what the customer is looking for.
• Increased flexibility: Because user stories don’t go into technical detail, they can be molded to fit changing situations.
• Improved collaboration: When team members are aligned on one goal, they can work better together and collaborate easily with other project stakeholders .

Though the benefits of writing user stories are significant, a product manager must also consider the potential disadvantages.

Here are a few user story pitfalls to watch out for:

• Incomplete stories: Though the language is intended to be informal, sometimes user stories are far too vague and exclude necessary details.
• Insufficient time: Writing a good story takes time. It requires extensive research and regular communication with stakeholders, a fact that is sometimes overlooked.
• Narrow vision: Because user stories focus on one single requirement, they can be hard to scale, and teams can sometimes lose sight of the bigger picture (in this case, an epic).

Before you start your story, take some time to identify potential risks or disadvantages and outline how you aim to counteract them.

Take your user stories to the next level with Wrike

After creating user stories, it’s time to work on the breakdown of your project. Wrike has the perfect solution for that.

With Wrike’s software, teams can easily implement Agile methodologies using custom workflows, Kanban boards, and pre-built templates. These features enable teams to kick-start projects quickly, visualize and progress, track time, manage tasks, and collaborate effectively. Agile development teams can also use Wrike to prioritize product backlogs, manage sprints, and run retrospectives.

Unlock the full potential of Agile methodology with Wrike’s customizable Agile teamwork template — simply customize it to suit your needs.

The Ultimate Guide to Story Mapping Tools

Basics of agile.

• 4 Pillars of Agile
• Disadvantages of Agile
• Agile Milestones
• Agile Iteration
• Agile Organization
• Agile Personas
• Timeboxes in Agile

Agile Teams

• Agile Team Charter
• Agile Leadership
• Agile Practitioner
• Agile Mindset
• Niko-Niko Calendar
• Agile Release Train (ART)

Agile Frameworks & Techniques

• Agile Iron Triangle
• Context Switching in Agile
• FDD in Agile
• Parking Lot in Agile
• Disciplined Agile Delivery (DAD)
• Agile Crystal Methodology

Guidelines for Agile Projects

• DevOps vs Agile
• Agile vs PMP
• How Does Agile Relate to PMBOK?
• Agile Business Process Management

Optimizing Agile Projects

• Story Splitting in Agile
• Definition of Ready
• Planning Poker in Agile
• Agile Three Amigos
• Agile Impediment
• Agile Information Radiator
• Burn Rate in Agile

Members-only Content

• Monthly Member Events
• Event Session Videos
• Experience Reports
• Research Papers
• Share a Community Event
• Submit an Article to the Blog
• Submit a Member Initiative
• Promote a Training Event

Become an Agile Alliance member!

Your membership enables us to offer a wealth of resources, present renowned international events, support global community groups, and so much more! And, while you’re supporting our non-profit mission, you’ll also gain access to a range of valuable member benefits. Learn more

• Join Us Today
• Member Portal
• Membership FAQs
• Terms and Conditions
• Corporate Members

Agile Conferences

• Agile en Español
• Agile MiniCon
• Agile en Chile 2024
• All Agile Alliance Events
• Past Conferences

Free Member Events

• Member Events Calendar
• BYOC Lean Coffee
• Agile Tech Talks
• Member Meet & Greet
• Agile Coaching Network
• Community Events
• Non-profit Events
• Agile Training
• Sponsored Meetup Groups
• Submit a Non-profit Event
• Submit a For-profit Training
• Event Funding Request
• Global Events Calendars

• Events Calendar
• BYOC – Lean Coffee
• Member Meet & Greet
• View All Events
• Submit an Event
• Meetup Groups
• Past Conferences & Events

Agile Essentials is designed to bring you up to speed on the basic concepts and principles of Agile with articles, videos, glossary terms, and more.

Agile Essentials

Download the Agile Manifesto

To download a free PDF copy of the Agile Manifesto and 12 Principles of Agile, simply sign-up for our newsletter. Agile Alliance members can download it for free.

• Agile Essentials Overview
• Agile Manifesto
• 12 Principles Behind the Manifesto
• A Short History of Agile
• Subway Map to Agile Practices
• Agile Glossary
• Introductory Videos

Recent Blog Posts

Reimagine Agile: Back to Basics, Forward to the Future

The State of Sustainability in Agile – Reflections on SoSA 2023

Meet the Agile2024 Program Team – Semira Allen

View all blog posts

Agile Resources

• Remote Working Guide
• Event Sessions
• Content Library
• Community Groups

Thanks in part to your membership, Agile Alliance supports and sponsors nearly 300 community groups around the world through a member-led initiative . Find a group near you, or create your own !

MEMBER INITIATIVES

• Agile Sustainability Initiative
• Agiledemics Initiative
• Principle 12 Initiative
• Agile in Color Initiative
• Agile Coach Camp Worldwide

View all initiatives

Your Community

Global development.

• LATAM Community
• India Community

• Community Services
• Member Initiatives
• LATAM Community Development
• India Community Development
• Volunteer Signup

Global Affiliates

OUR POLICIES

Become a sponsor.

Being an Agile Alliance sponsor is a great way to introduce your company to our members to build awareness around your products and services. Agile2023 sponsorships are going fast, but they’re great opportunities still available! Learn more >

• About Agile Alliance
• Code of Conduct
• Board of Directors
• Agile Alliance Brazil
• Agile Alliance New Zealand
• Policies, Reports & Bylaws
• Logo and Media Files
• Become a Sponsor

User Story Template

> agile basics: get started in agile in just half a day – october 17th, what is user story template.

A user story template is a common format used to write  user stories that help you include key pieces of information about that user story.

One particular template, often referred to as “As a… I want to… So That…” is the most commonly recommended aid (often outgrown once past the novice stage) for teams and product owners starting to work with user stories and product backlog items in general:

• As a (who wants to accomplish something)
• I want to (what they want to accomplish)
• So that (why they want to accomplish that thing)

An example:

• As a bank customer
• I want to withdraw money from an ATM
• So that I’m not constrained by opening hours or lines at the teller’s

Also Known As

Another name is the “Connextra format”, in recognition of its origins (see below).

Expected Benefits

This template serves as “training wheels”, reminding people in conversation about user stories to pay attention not just to “what” the desired software product is to do, but also “for whom” it does it and in pursuit of “what objectives”.

Common Pitfalls

Many novice teams fall into rote application of this or some other user story format. In fact, such formats are intended more as checklists. A more relaxed phrasing is often just as effective at communicating the overall intent of a user story. Since the greatest amount of detail about a user story will in any case arise in conversation between members of the team, often quite sometime after initially writing a story card, spending much effort and time on complying with user story templates is without much point.

• 2001: the “role-feature-reason” format for expressing user stories is invented at Connextra in the UK

<  View all Glossary Terms   |  Provide feedback on this term

Join us today!

Agile Alliance offers many  online and in-person events and workshops  for our members. If you’re not currently a member, you can  join now  for just $49 per year.

Get the latest Agile news!

• Comments This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy , and agree to receive our emails.

Additional Agile Glossary Terms

Acceptance testing, heartbeat retrospective, product backlog, help us keep the definitions updated, discover the many benefits of membership.

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Our Cornerstone Corporate Supporting Members

Our Corporate Supporting Members are vital to the mission of Agile Alliance.  Click here to view all corporate members.

©2023 Agile Alliance  |  All Rights Reserved  |  Privacy Policy

©2023 Agile Alliance All Rights Reserved  |  Privacy Policy

• Welcome back!

Not yet a member? Sign up now

• Renew Membership
• Agile Alliance Events
• Agile en Chile
• Resources Overview
• Agile Books
• Content Library by Category
• Content Standards
• Privacy Policy
• Cookie Policy

Privacy Overview

Try for free

How to Write Perfect User Stories (With Templates): A Step-By-Step Guide

Following user stories templates step by step

How to write a user story using the 3 c's template, 4 user stories templates you can start using today, user stories templates: word or excel, airfocus' 5 top tips for writing user stories , how to write user stories in airfocus.

Any product manager knows just how critical writing good user stories is in ensuring a product's success. But it’s also pretty easy to make user story mistakes ! So, in this guide, we’re going to give you the tools and knowledge you need to write clear, effective user stories.

The key questions we’ll answer are:

How do you write a perfect user story — what are the essential ingredients?

How do you structure a user story?

How to choose the right format for user story

Let’s get started!

Get started with product management templates

.css-uphcpb{position:absolute;left:0;top:-87px;} What to know before you write a user story

The 3 c's of user stories.

Card, conversation, and confirmation is a formula created by Extreme Programming (XP) co-founder Ron Jefferies in 2001.

Jefferies looked to improve output by simplifying user stories templates, turning them into a tool that could be understood by anyone, including developers, stakeholders, and customers. 

The 3 C’s framework gives us a user story template that captures the components of a user story. 

Card - A card or sticky note is used to give a physical manifestation of the user story. This helps to cement the requirements in the team’s heads as there is a physical representation, rather than a hypothetical idea.

Conversation - This refers to the second stage of working with user stories: how to achieve the card’s requirement. Teams will discuss, ideate, and ask questions to develop a shared understanding of the situation, as well as potential solutions.

Confirmation - The final C refers to the process of solidifying plans to move forward. The team will use decision-making frameworks to figure out the optimal solution, taken from the Conversation stage to solve the requirements from the Card stage.   

The 3 C’s framework covers the end-to-end process of a user story. The card offers a visualization of a real user pain point, which triggers a deep, meaningful conversation about how to solve that issue. The final confirmation stage ensures that no user story goes unanswered and teams aren’t moving on to other tasks, leaving the user story unfinished.

User stories should incorporate agile principles, including:

The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Working software is the primary measure of progress.

Simplicity.

Capturing user stories on cards is a great way to incorporate the 3 C’s into your agile working environment. As with other agile ways of tracking progress, cards can be easily moved around to clearly indicate priorities.

Agile user stories are prioritized and visualized with cards to ensure the entire team is aligned with the current goals. 

INVEST in great user stories

The key to writing an effective user story is to determine the who , what , and why . To do this, you should follow the INVEST framework to ensure your user story touches upon everything that’s required. 

Let’s quickly look at what INVEST represents.

Independent

Every agile user story must be independent and should stand on its own. User stories should be workable in any order as much as possible and you should be able to move a user story around the backlog . This is helpful when prioritizing , especially when dependencies come into play, as it may not be possible to implement a valuable story without implementing other much less valuable stories.

A user story should capture the essence of what is required from the customer’s viewpoint. It’s not a technical specification, but more of a conversation starter.  

There needs to be a collaboration between teams and customers when implementing user story templates. The final deliverable should be created based on in-depth discussion and collaboration, and this is where the negotiation comes in. 

As a collective, you must decide what can add value to the product and what should be left behind. This will help build something that is truly brilliant, rather than simply filling the checkboxes of the user story. 

Every single user story should add value to the project/product . If any stories fail to have any discernible value, then they should be rewritten or scrapped entirely. With your user stories being prioritized in the backlog according to business value, it should be simple to spot anything that doesn’t add value.

A story has to be able to be estimated or sized so it can be properly prioritized. Being able to estimate a timeframe for user stories allows for better prioritization , as a valuable task that takes a long time to complete may be pushed to a lower priority level while the team focuses on high-value, fast-completion tasks. 

When estimating agile user stories, you should be able to easily distinguish between high and low-effort stories. If a user story cannot be estimated, it should be rewritten in a way that makes the scope of the story clearer. You can also look at splitting a user story into multiple stories to help improve clarity. 

User stories are not technical specifications, nor are they detailed accounts of customer pain points. As we mentioned earlier, they should simply capture the essence of customer requirements. Stories are gateways to further discussion and shouldn’t replace the discussion itself. 

One of the best indicators that you’re writing effective user stories is testability. Every story needs to be testable in order to be “done”. To achieve this, try writing the acceptance criteria before implementing the user story.

Cut through the clutter of PM Content with our bi-weekly digest

Once you’ve got to grips with the 3 C’s and the INVEST framework, it’s time to write your user story! Let’s break down that process into simple steps.

1. Define your end user

In order to write an effective user story, you first need to identify and define the user. Who will be using your product? 

A helpful trick to help you visualize your user is to create persona profiles. A user persona is an archetype or character that represents a potential user of your website or app.

Creating a persona essentially gives you a fictional person that represents the needs of your customers. Add their relevant attributes, attitudes, and behaviors to help give context to the voice of the customer and any customer-focused decision-making. It also helps to give the person a name and find them a photo to create a sense of a real person. 

2. Specify what your end user wants

Now you have your user persona, it’s time to dive into the detail. What exactly does your customer expect, need, or want from this product?  

This step will require you to look at market research and customer feedback to identify real needs, rather than assumptions about your user needs. You can also refer to the “goal” section of your persona profile, then add a brief description of this to your story.

3. Describe the benefit of your product

Put yourself in your user's shoes for a moment. What benefits will they receive from this item? 

For this stage, it’s also helpful to ask the question “why will customers choose our product over our competitors?”. This will help everyone to understand the value of that user story and help with prioritization.

4. Add acceptance criteria

In agile, teams are required to deliver products that are potentially shippable. Acceptance criteria is the clearest and quickest way to determine whether a user story is done or not.

Each user story should have at least one acceptance criteria but try not to list too many. You can use S.M.A.R.T objectives to ensure your criteria are measurable. Always remember to write from your end user’s perspective and not confuse acceptance criteria with a to-do list.

The card represents 2–3 sentences used to describe the purpose of the story.

The card is usually in the following format:

As a <Role> I want <goal>so that <benefit/expected outcome >

The written text must address the “who (role)”, “what (goal)” and “why (benefits)” of the story.

2. Conversation

The collaborative conversation facilitated by the product owner involves all stakeholders and the team. This conversation is mostly verbal, where a detailed description of the user story is discussed. The written Card is modified to reflect the current shared understanding of this conversation.

3. Confirmation

Confirmation represents the acceptance criteria, which is how the product owner will confirm that the story has been executed to their level of satisfaction. Confirmation represents the conditions of satisfaction.

A simple user story template

This starter template will help you write user stories and acceptance criteria and organize them in one easy-to-read view. You can also add details like a priority and estimated effort.

Epic user story template

Some agile teams use epics to group related user stories into a larger category. This user story template will help you capture epics and user stories in one place.

Thematic user story template

Themes are at the top of the agile work hierarchy — above epics and user stories. They represent major investments in strategic initiatives and convey how you intend to make progress toward your overall business goals.

With this user story template, you can keep your strategy top-of-mind during the development process by associating your user stories with different themes. You can also add a column to include your epics if you use them.

SAFe user story template

Teams practicing certain agile methodologies may prefer to include additional details when writing user stories. For example, organizations that implement SAFe® often add in the benefit hypothesis, nonfunctional requirements, and cost of delay.

Here is a more detailed user story template that aligns with SAFe® methodology:

With the majority of user stories templates being some form of a table, Excel may be the first place that teams go when it comes to creating a user story template of their own. But while it’s easier to build a table in Excel, it’s not the most user-friendly program in the world. 

User stories may need to be rewritten as specifications and user needs change, so you need to build your user stories in a program that allows for quick, simple edits. And that’s why some teams prefer to use word processing software for user stories than a spreadsheet database.

User stories capture the essence of why we’re building a product. It's essential to align user stories with business goals , incorporate user feedback , measure success with metrics, and collaborate with stakeholders. Because user stories are shared between multiple parties, keeping things simple, clear, and concise is important. 

By following these tips, you can write user stories that deliver value to your users and your organization.

1. Align User Stories with Business Goals

The purpose of user stories is to deliver business value. So, aligning user stories with your organization's overall business goals is essential. Every user story should contribute to achieving the organization's strategic objectives. This ensures that the product will positively impact the business and allow product managers to allocate resources toward the right priorities.

2. Incorporate User Feedback into User Stories

If you haven’t spoken to the people who will use your product, there’s no point in writing user stories. It's crucial to involve users in the development process to ensure their feedback is considered. Gathering user and stakeholder feedback helps ensure user stories reflect user needs. This also helps build a sense of ownership from the users, increasing brand loyalty and word-of-mouth marketing.

3. Use Metrics to Measure User Story Success

Measuring user stories' success is essential to determine if they are delivering the intended business value. Metrics can measure user stories' impact on user satisfaction, conversion rates, revenue, and other relevant business metrics. Using metrics helps identify areas that need improvement and make data-driven decisions .

4. Collaborate on User Story Development with Stakeholders

User stories are a collaborative effort involving multiple stakeholders . It's crucial to involve all relevant stakeholders in the development process to ensure user stories reflect their needs and priorities. Collaboration also helps identify potential roadblocks and ensure all stakeholders are aligned with the project's objectives.

5. Keep Things Simple, Clear, and Concise

User stories should be simple, clear, and concise. They should be easy to understand by all stakeholders, including developers, designers, and product owners. Stick to the traditional user story template and avoid using technical jargon or complex language that may confuse users. User stories should be short and focused on a specific user need, making it easier to prioritize and implement.

At airfocus, our priority is to help product managers develop the best products. PMs can use airfocus’ many features to easily create holistic user stories.

Insights by airfocus

Product managers can leverage our Insights feedback management tool to get all the background info you need about your users. Insights allows product teams to take note of every single piece of customer feedback, no matter the source. It gathers user feedback from a variety of channels, like email, social media, and web chats. This comprehensive collection of customer feedback is invaluable at the user story stage, as it fills in the blanks in your user story.

airfocus Portal

There’s no such thing as too much customer feedback. Product teams can use airfocus to create a customized Portal to get feedback from your users. Using Portal to help write user stories can help teams quickly identify core issues that need to be addressed and discover feature requests that truly add value to new products or updates to existing products.

The airfocus Portal is also invaluable for building new products from scratch. It’s a great brainstorming tool bringing together customers, stakeholders, developers, and anyone else with a vested interest in your new product. Rather than collecting vague feedback and guessing where to go next, you can make truly informed decisions based on real customer needs.

Ask AI for some help with AI Assist

We all get a little stuck sometimes, especially in these early stages of product development . In these times, you often just need a tiny spark that ignites the productivity fire. Thankfully, airfocus has that spark ready for you with AI Assist . AI Assist for airfocus saves product managers time by kickstarting almost any planning tasks you need to do. It can even write fully fleshed-out yet concise user stories with a quick slash command.

Don’t forget our resource hub!

If you’re feeling a little rusty or simply want to level up your skills, airfocus has a huge range of resources available. We have everything you need to brush up on your user story skills and much more with our various resources, including ebooks , our blog , and our extensive product management glossary . 

Experience the new way of doing product management

Book a demo

Instant tour

How to Write Great Agile User Stories

• agile , agile user stories , user stories

User stories are a valued component of agile or scrum development. In project management, user stories helps keep teams focused on the end goal of “why” a feature is needed. It also helps to provide a deeper context for everyone working on sub-items related to a larger feature. Writing user stories for agile or scrum is easy. In this post we wanted to give you some examples and guidance on how to write better user stories.  

Why Write User Stories?

Precise and simple communication

Simply listing a set of tasks for your team, while sometimes effective, can be confusing. This can stem from a number of causes: vague context, unclear expectations, and being overly technical.

Task: Implement Sprintly GitHub Integration

User Story: As a user, I want Sprintly to integrate with GitHub so that I can view GitHub activity related to a Sprintly item, in the item’s activity feed.

The user story makes it clear that the integration needs to result in GitHub activity being tracked in Sprintly . In comparison, the task merely  suggests that integration is needed, but it’s not clear how a user would benefit from it.  

For large requirements documents or use cases, it’s easy for the value and focus to get lost . User stories are the perfect middle ground between large, overly detailed documents and vague tasks.

Software development teams are always on a time-crunch. User stories are easy to understand, relatively easy to write, and easy to maintain. A user story is written in plain English, which avoids confusion with unfamiliar terminology or jargon. During time sensitive projects, quickly pushing out several user stories works great at providing your team with an overall understanding of the project. Details and sub-items can be added as needed, but quickly defining the user stories will get everyone working on relevant tasks sooner.

Allows room for interpretation, creativity, and conversation

Nobody wants to be given a list and told exactly what to work on or build. The best user stories help the team understand broad goals and context which then sparks discussion and collaboration. It is also useful in eliminating hidden assumptions team-mates might have about a task.

User stories allow you to say why the features you’re proposing to build makes sense . A user story answers 3 important questions:

• Who are you building this for?
• What are you building?
• Why are you building this?

Answering these questions will tell your team the specific circumstances to build by so that they can work appropriately. For example, take a look at how the context of a user story is greatly affected by one of the three components:

As a user, I want to filter items by item type so that I can see how my team’s time is being used between features and bugs on a weekly basis.  

As a user, I want to filter items by item type so that I can create a report on everything we did this month for my boss.

Notice how changing one component of a user story would change your approach entirely? In the first case, you would probably display this information in a chart or graph for a simple breakdown of your team’s time. In the second example, you would likely create a function to export the data so it can be shared and presented.   

With user stories, everyone in your team knows exactly “who,” “what,” and “why” they are building features. Each component adds a necessary layer of context to give your team a proper start. A user story immediately directs the focus to a specific circumstance which provokes further discussion and careful revision. The end result is that your team becomes more focused on delivering solutions to user problems as opposed to merely delivering functional code.

How to write user stories

Now that we’ve listed some reasons why you should write user stories, here’s how to actually write them.

I.N.V.E.S.T.

The I.N.V.E.S.T. guideline to writing user stories is almost universally accepted as the standard to work by. The acronym was made popular by Bill Wake’s original article from 2003. Our interpretation:

(I)ndepdendent: You should be able to prioritize and rearrange user stories in any way with no overlap or confusion.

(N)egotiable: As previously discussed, a good user story can be reworked or modified to best suit the business. User stories are not an explicit set of tasks.

(V)aluable: User stories need to be valuable. By this, we mean valuable for the business or the customer. If it’s not, why would you have your team work on it?    

(E)stimable: A good user story can be estimated. It’s also important to differentiate time estimations from an exact timeframe . A rough estimate is beneficial to allow teams to rank and schedule their priorities. At Sprintly, we allow users to categorize their stories and sub-items into sizes (small/medium/large/extra large) so that they can better prioritize their stories.

(S)mall: We definitely recommend keeping your user stories small. While we don’t suggest an exact timeframe to stay in, writing user stories that focus on smaller tasks allows for greater focus. The larger a story is, the harder it is to estimate and easier it is to get caught up in sub items that should have probably been their own stories.

(T)estable: Before a user story is written, it is essential that a criteria to test it is in place. Outlining the testability first ensures that the story actually accomplishes the goal you are trying to achieve. A story is not finished until it is tested. For maximum productivity and team alignment, make sure your team knows how their work will be tested.

We tend to view testability as the fourth major component of a user story. Having your team know your stories’ testing parameters beforehand plays a big role in how they decide to take it on. 

With I.N.V.E.S.T. in mind, you can now start thinking about writing user stories. At Sprintly we consider any project that contains sub-components a good candidate for a user story. Sub-items are tasks or tests you can list under your user story to provide a clearer vision of what needs to be done before the user story is complete.

Once again, it’s important to remember that everything about a user story, including its sub-items, can be reworked to best fit the needs of your business. Sub-items are great for providing additional direction and details for what needs to be done. Take this user story for example:

Sprintly supports collaboration on both the main user story and its sub-items, allowing team members to comment, tag other team members, make edits, and more. The more communication there is around stories and tasks, the better the outcome. 

Things to avoid when writing user stories

While we think writing agile user stories isn’t difficult, there are still ways you can mess it up. Here are some common pitfalls you should avoid.  

Increasing the scope of your stories

Knowing that it’s good to rework and modify your user stories, it’s easy to end up increasing the scope of your story and taking away from its effectiveness as an agile tool. Don’t be afraid to break a story into two  if the scope becomes unworkable.  On the other hand, reworking a story to decrease the scope should be a welcome time saver for your team.

Treating technical tasks like they are user stories

It’s easy for your team to get in the habit of framing everything as a user story. Sometimes teams might go so far as to take simple technical tasks and conceive those as stories. This is sometimes because they feel stories need to be broken down into smaller and smaller pieces. Other times it comes from the way a team tracks velocity and could be a symptom of your team not understanding the difference between tracking effort versus results . Going out of your way to label tasks as individual stories will just create confusion and waste everybody’s time.

Rewording the “want to” phrase as the “so that” phrase

“As a user , I want to be able to access my client list so that I can view my client list .”  

Getting to the value part of the user story right is often tricky. Without proper analysis , you can easily end up with a story that describes what you are building, rephrased in 2 different ways, without answering the “why.” In the user story example above, it doesn’t describe why the user wants to view the client list. Making sure that there is an answer to the “Why?” is important. 

Including multiple components in your user story

“As a user , I want to be able to access my client list so that I can save, share, and email the client list .”

You may be tempted to write comprehensive  user stories that include either multiple “want” components, “so that” components, or both. It’s important to remember: if you can divide a user story into multiple ones, you should do it. Don’t worry about filling or “wasting” space on a board with your stories. If your team can understand what needs to be done, you are doing the right thing.             

User stories are a great tool to aid your software development process. They are easy to work with and relatively simple to master. We hope our overview on user stories will help you and your team get started.

Interested in trying out User Stories in Sprintly?  Sprintly requires no configuration or training and your team can be up and running in seconds. Click here for a free 30 day trial (no credit card required) .

Sign in and check out:

• Your team's progress • GitHub integration • Productivity analytics

Sign in with GitHub

How to Write Good User Stories in Agile Software Development

Teagan Harbridge

For many software development teams striving towards agile, the idea of writing user stories can seem like another “thing” agile piles on top of their already busy workloads. We hear you, we’re busy too!

But if you’re reading this blog post, it means you definitely have some time to spare to write user stories. And good ones at that!

Let’s start off by looking at what a user story is, and isn’t.

A user story helps agile software development teams capture simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written is “dev” speak.

How do we write user stories?

A user story often follows the following ‘equation’:

As a <type of user>, I want <some feature> so that <some reason>

Let’s break this down one step further;

As a <type of user> — this is the WHO. Who are we building this for? Who is the user? I want <some feature> — this is the WHAT. What are we building? What is the intention? so that <some reason> — this is they WHY. Why are we building it? What is the value for the customer?

Let’s look at a few simple examples;

As an internet banking customer I want to see a rolling balance for my everyday accounts So that I can keep track of my spending after each transaction is applied

As an administrator I want to be able to create other administrators for certain projects So that I can delegate tasks more efficiently

Following this equation, teams should make sure that their user stories are ticking all of the following checkboxes:

“Why can’t we just write features or tasks instead?”

And it’s a great question. Though most teams asking this question, usually don’t understand the value of writing user stories, and the fact that they serve very different purposes to that of features.

The fact is, it’s easy to get buried in a contextless, feature developing cycle. The objective becomes more about clearing your way through a laundry list backlog, than it is about building solutions that add value to your customers. Your human customers. User stories bring that context and perspective into the development cycle.

Acceptance Criteria

User stories allow teams to have one hand on the needs, wants and values of their customers, and another, on the activities they need to accomplish to provide that value.

The link pairing these two things together, is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of a user’s requirements. They help the team to understand the value of the story and set expectations as to when a team should consider something done.

Acceptance Criteria Goals

• to clarify what the team should build before they start work
• to ensure everyone has a common understanding of the problem/need of the customer
• to help team members know when the story is complete
• to help verify the story via automated tests

Let’s look at an example of a completed user story with acceptance criteria;

| As a potential conference attendee, I want to be able to register for the conference online, so that registration is simple and paperless.

Acceptance Criteria:

• Conference Attendance Form
• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)
• Information from the form is stored in the registrations database
• Protection against spam is working
• Payment can be made via Paypal, Debit or Credit Cards
• An acknowledgement email is sent to the attendee after submitting the form

With this in mind, teams should make sure that their acceptance criteria is ticking all of the following boxes;

Acceptance criteria should NOT include the following:

• Code review was done
• Non-blocker or major issues
• Performance testing performed
• Acceptance and functional testing done

Your acceptance criteria should not include any of the above, because your team should already have a clear understanding of what your Definition of Done (DoD) includes, for instance:

• unit/integrated testing
• ready for acceptance test
• deployed on demo server

Looking to get your team started writing user stories, but not sure where to start?

READ NEXT: The Guide To Agile Ceremonies For Scrum

Written by Teagan Harbridge

Talented gift wrapper, amateur soccer player, passionate Harry Potter enthusiast and Head of Product @easyagile

More from Teagan Harbridge and Easy Agile

How to Run PI Planning in Jira — Helping make SAFe®, Easy

If you’re reading this, then you’re officially on the train; the agile release train (art) that is — and you’re attempting to navigate the….

Nicholas Muldoon

The Difference Between a Flat Product Backlog and a User Story Map

It’s one of the most common practices in agile software development; the flat product backlog. we’ve all seen them, we’ve all contributed….

Anatomy of an Agile User Story Map

Introducing Easy Agile Programs — The Complete Program Planning Solution for Jira

The easy agile team is incredibly excited to announce the official launch of easy agile programs for jira., recommended from medium.

Kshitij Saxena

How to set up and implement your Product Documentation structure?

Learn how streamlining documentation management for efficient cross-team collaboration and select the right tool in this comprehensive….

Samuel Edwards

Scrum Components: User Stories Acceptance Criteria

Good Product Thinking

General Coding Knowledge

Stories to Help You Grow as a Software Developer

Coding & Development

How Agile could work in data teams — Scrum & Kanban

One of the possible ways to organize data team workflow.

Gökrem Tekir, PMP

Project Management Knowledge

Storyboarding in Collect Requirements Process

Creating a sequence of illustrations.

Oksana Holubets

Continuous Discovery process in JIRA

How to set-up the continuous discovery process in jira and align it with agile methodology and delivery process..

Marie Lefevre

Towards Data Science

Data Documentation 101: Why? How? For Whom?

Best practices for establishing complete and reliable data documentation within your organization.

Text to speech

1. 🤔 WHAT IS A USER STORY?

PRODUCT STRATEGY

How to Write a Good User Story: with Examples & Templates

Published: July 20, 2018

12 min read

Last updated: May 2, 2022

Andrii Bondarenko

Content Team Lead @ Stormotion

In this article, you'll learn:

🤔 What is a User Story?

👍 what are the benefits of creating user stories, 📝 how to write user stories: our workflow, 💡 conclusion.

When you start to dive into Agile, the first thing you notice is how user-centered this approach is. It shifts the focus from just coding and designing to delivering real value to your end users, stakeholders and business in general.

Agile User Stories are an essential component of this ideology that lets you define what benefits your product will bring to your target audience (and, eventually, how it will boost your KPIs and other metrics).

User Stories help to constantly improve the value of your product to the end users ( image by Aleksandar Savic )

We at Stormotion love Stories. As an Agile-driven Team we actively use them to get a better understanding of what benefits our clients’ products deliver to their end users. They also drive collaboration and creativity, pushing us to non-trivial development solutions.

So today we’re going to share our knowledge and experience on this matter to help you improve your Story-writing skills. Enjoy!

User Stories are one of the core elements of the Agile methodology. However, they’re often jumbled with software requirements which isn’t true. So what is a User Story?

User Story is a small (actually, the smallest) piece of work that represents some value to an end user and can be delivered during a sprint.

The main aim of this element is to put end users in the center of conversation and capture product functionality from their perspective. Thus, developers get a better understanding of what, for whom and why they’re building.

User Stories help understand what value a product provides to its end users ( image by Duo )

Great User Stories always fit the INVEST set of criteria by Bill Wake:

• I ndependent – they can be developed in any sequence and changes to one User Story don’t affect the others.
• N egotiable – it’s up for the team to decide how to implement them; there is no rigidly fixed workflow.
• V aluable – each User Story delivers a detached unit of value to end users.
• E stimable – it’s quite easy to guess how much time the development of a User Story will take.
• S mall – it should go through the whole cycle (designing, coding, testing) during one sprint.
• T estable – there should be clear acceptance criteria to check whether a User Story is implemented appropriately.

The User Story format (which is used by the Stormotion team as well) is quite plain and short:

As a [type of user], I want [an action] so that [a benefit/a value]

Looks like nothing difficult, huh? Here are a few User Stories examples that fit some made-up taxi app project:

• As a driver , I want to block badly behaved passengers so they are never shown me again .
• As a passenger , I want to link the credit card to my profile so that I can pay for a ride faster, easier and without cash .
• As a driver , I want to add photos of my car in my profile so that I can attract more users .
• As a passenger , I want several available drivers to be displayed so that I can choose the most suitable option for me .

Sounds quite easy but User Story development isn’t often that simple. Yet, later on, we’ll share some of our proven tips that will help you make only good shots.

A few more examples of User Stories for websites ( image by Philipp Kühn )

Is there something else?

Despite we’ve just figured out that Agile User Stories are independent and should be understood as totally separate units of work, sometimes they’re grouped together. So when working with them you are likely to meet and use the concept of an Epic . What is it?

An Epic is a high-level body of work that bands together with a group of related Stories.

We at Stormotion use Epics to describe more complex tasks and create a clear hierarchy that allows managing development more easily and delivering new value to the users while working towards a bigger goal. Yet, the User Story format itself stays the same.

The hierarchy of Epics and Stories ( image by Atlassian )

Let’s learn how they compare to the User Story format:

Imagine that you’re building a dating app. In this case, good Epic and User Story examples (but don’t take them too seriously) will be:

So, Epics provide us with a high-level view of our goals and how we’re moving towards them. It also helps us during the prioritization process since we can check which Epics require our attention the most and, therefore, which Stories should be implemented first.

How to Prioritize the Feature Development

Oh, one more thing!

Don’t forget to add an acceptance criteria .

An acceptance criteria is a set of conditions that are used to confirm when a Story is completed.

Every Story should have clear acceptance criteria ( image by Hai Peng )

Also, these conditions provide us with a deeper and better understanding since they include key info on how Stories perform. Let’s reuse one of the User Story examples from the beginning of the article:

As a passenger, I want several available drivers to be displayed so that I can choose the most suitable option for me.

What acceptance criteria can be applied to this Story?

• The app shows drivers that were online within last 20 minutes and don’t have an ongoing ride.
• The app shows only 5 drivers that are closest to the user.
• A user can browse profiles of these drivers, including their photos and rates.

As you can see, now we not only know the value of this Story to users but also understand some key characteristics that require special attention during implementation.

However, you're free to choose how detailed your acceptance criteria will be. It can range from "just let it work in any convenient way" to even more detailed sets of conditions than in the example above.

That's greatly depends on your development team so there's no "correct answer". If your team needs guidance and clear, with-no-room-for-interpretation tasks you'd better stick with detailed instructions on how stories should perform. Otherwise, the "just get it done" approach may work as well.

How to Evaluate Your Startup Idea

Wow, it’s been said a lot about User Stories. But why are they so important to Agile teams?

If you were ever involved in working with Agile frameworks, you already know that both Scrum and Kanban teams greatly benefit from writing User Stories.

User Stories provide benefits for all kinds of Agile Teams ( image by Andrew McKay )

In Kanban, teams accumulate Stories in a Backlog and then run them one by one to support the work-in-progress flow. This helps to constantly stay on track and improve development team KPIs.

Scrum (which we usually prefer at Stormotion) teams also love User Stories. We actively use them to make estimations, prioritize and plan sprints which helps us stay agile and flexible to any changes. This is especially beneficial when we’re working with Startups that are at the MVP-Stage and have limited resources before pitching their project to Angel Investors.

Stories are actively used by Kanban teams as well ( image by Tahir Yousaf )

Except for the above-mentioned, there are some vivid benefits that are common to all Agile teams:

• Keep you focused on the business value. It helps to make your app not only well-built from the technical perspective but also useful to the end users.
• Enable creativity. Since it contains a minimal amount of info, your team is free to drive creative ideas to find the best solution to implement a Story.
• Your project becomes more manageable. We at Stormotion know that it’s a way easier to work with small and estimable Agile User Stories rather than with big complex tasks.
• They inspire the team! Every developer loves this sweet feeling of a small win which motivates him to work even harder.

Now let’s dive into the process of creating a User Story!

Project Discovery: What's and Why's?

We’re getting to the most thrilling part of our article. However, before we share our step-by-step instruction on writing a User Story, it’s crucial to figure out 2 essential questions: who and when makes them.

Who is responsible for creating a User Story?

As a rule of thumb, Stories are mainly written by Product Owners since it’s their responsibility to keep the Backlog filled with tasks. Yet, don’t forget that Agile is based on communications and opinions exchange between experts. So...

It doesn’t necessarily mean that they should be written only by a Product Owner. The more people join the conversation, the better.

At Stormotion, Stories are written by all team members who are related to the business-side of the project (sales managers, marketers, a product owner etc.), since it let us look at the future app from the perspective of any potential kind of user. The responsibility of the Product Owner in this case is to confirm that they’re match the INVEST criteria.

Stories are created through collaboration ( image by Dmitrii Kharchenko )

When are User Stories created?

A Story-writing meeting in our HQ is usually held near the start of the project . We prefer to gear ourselves up to make sure that a project goes well from the first day to the last.

Later on, we’re able to use our Scrum User Story list to prepare more detailed estimates (for example, by the end of the Discovery Stage), prioritize feature development for sprints and so on.

How to Estimate Software Development Time Accurately?

Also, we supplement the original list as we work on a project with new stories to stay up-to-date with our client’s requirements.

What are the steps to write great Agile User Stories?

First, let us remind you of a common User Stories template:

Seems short and easy to write. By the way, you're welcome to create your own User Story template. However, we at Stormotion have a specific workflow that helps us deliver the best Stories:

• Make up the list of your end users. Define what their “pain” or “need” is, which you’re trying to solve.
• Define what actions they may want to take.
• Find out what value this will bring to users and, eventually, to your product. Also ask yourself - will any party pay us for this?
• Discuss acceptance criteria and an optimal implementation strategy.

Let’s look them over now!

Step 1: Think of the “Who”

This is the first and, maybe, the most fundamental step. Before writing a User Story you should actually know who the end users of your product are. And more important - what needs they have, which you are trying to cover.

During our Story-writing workshops, we try to omit using such a role as simply “the user”. It can be applied to any person - from your customers to admins - and, therefore, it doesn’t reflect the personality of particular target groups, the way they interact with the application.

It's important to correctly define your user persona ( image by Grzegorz Oksiuta )

If you want to achieve really great results you may want to dive into your audience even more. Instead of just naming users after their role (for example, “a driver”) try to create some kind of a buyer persona.

Here are a few more tips from our own experience:

• It’s all about the user. Not about developers. And even not about a Product Owner. Each Story should be valuable to some group of your end users.
• Don’t think of users only as external customers. It’s true that your Stories will be mostly about them. But it’s also true that you have to consider internal users such as admins, editors etc.
• Feel some empathy. Give your “user” a name. Think of his mobile habits, what issue your app is going to get resolved for him and how you’re going to make this path easier and faster. Remember some people who you know from the real life and who fit this portrait; feel how you relate to this target group.

Step 2: Think of the “What”

Now we have a few groups of end users. The next step we do is define what functionality each user expects, how he’s going to interact with the app.

Then you should find out how users are going to interact with your product ( image by Johny vino™ )

These are the main rules to remember when writing an action for a Kanban or Scrum User Story:

• One action per a Story. If you want to write something like “as a customer I want to browse items and add them to the cart” you’d better split it into 2 separate Stories.
• Describe an intention, not a feature. For example, instead of “I want to manage my profile” create a few Stories like “I want to be able to register”, “I want to upload my profile photo”, “I want to link my credit card to my profile” - each Story will have a different value.
• Keep it short. Users don’t care what library you will use to let them browse the list of items so leave all the tech details aside.
• Avoid describing UI. We’ve defined Stories as negotiable, remember? That's why all good User Story examples don't include any UI details. So don’t try to compose any special way to implement them (we’ll do this later).

Step 3: Think of the “Why”

Finally, the last piece of our User Stories template is dedicated to a value that users get after performing an action. It may seem like not a big deal but it’s often the most tricky part of User Story development.

Pay attention to how users interact with your application ( image by Andrew McKay )

However, your [so that] section should always correspond with your metrics and KPIs. It should either improve the UX, increase retention rates, shorten users’ journey to the issue solution or whatever. Each Story should contribute something to the general goal of your product .

If you can’t answer what value this feature brings to end users and your product as well, then you’re doing something wrong.

For instance, there are a few User Stories examples with a well-written value for our ongoing food ordering app project:

• As a customer, I want to get notifications when there are new hot offers so that I never miss the best deals. [how it affects KPIs: users get notified ➡️ they use the app more often ➡️ retention rate grows].
• As a restaurant manager, I want to complement dish description in the menu with a photo so that it looks more attractive to the customers. [how it affects metrics: users are satisfied that they can see photos ➡️ sales grow ➡️ your revenue also grows].

Step 4: Discuss a Story

Finally, we always discuss User Stories after they’ve been created. Even if it seems like nothing to talk about.

Don't underestimate the importance of the brainstorming session ( image by Monika Pola )

During this Q&A session, we ask the author of the Story to provide more details or clarify something if needed. It helps us understand how it should work and agree on acceptance criteria. This way we review all mobile app user stories examples one by one.

Then we hold a brainstorming session with the whole team working on the project. It allows us to find out the best ways to implement User Stories from the tech perspective.

How to Select an Agency for Your App Development?

So that’s how to write User Stories in a nutshell. Our Stormotion Squad also uses the following tips when working on this task:

• Start with Epics. It’s usually easier to move from more complex tasks to more specific ones so try writing Epics and then split them into Stories.
• Listen to feedback. Sometimes you don’t need to guess Stories - ask your real end users for feedback and use their ideas as a source of inspiration.
• Don’t introduce details too early. It’s better to hold the brainstorming session before each sprint to discuss how to implement planned Stories.

User Stories are an essential element of the Agile approach that can bring many benefits to your project. However, it’s important to write them correctly which requires some time and skills.

Examples of good User Stories meet the INVEST criteria, meaning that they’re:

• I ndependent
• N egotiable

The common User Stories template includes the user, the action and the value (or the benefit) and typically looks like this:

As a [type of user], I want [an action] so that [a reason/a value]

User Stories can help you to constantly improve the value of your product, estimate development efforts in an appropriate way and prioritize feature development during the MVP and post-MVP stages.

Boost Your App Development With Us!

Was it helpful?

About author

Content-Marketing Maestro @ Stormotion. Crafting compelling stories for a brighter world.

Andrii Bo...

Author page

Stormotion's ChatGPT Journey

10 MIN READ

Top 5 Best Practices for Integrating ChatGPT in Your App

DEVELOPMENT

11 MIN READ

How to Build SaaS App Like Spotify

How can we help you?

Please tell us about your project

By sending this form I confirm that I have read and accept the Privacy Policy

Our clients say

They make the whole business work for us, and their improvements are fundamental to our operations. They’re reliable, honest, and willing to try new things that will help us. We appreciate how flexible and easygoing they are.

Pietro Saccomani, Founder

⏰ Save your team time by improving your Standup meetings →

45 User Story Examples To Inspire Your Agile Team

Writing user stories is a critical skill for agile teams, yet it can be challenging to master. A good user story guides your team’s work, ensuring your efforts create real customer value. But sometimes you need some user story examples to get you inspired! This article provides user story examples in different contexts, so you have a library to reference for inspiration when you write your own. 

User stories in Agile: General examples

User story examples for different domains and platforms, user story examples for websites, user story examples for login, user story examples for registration, user story examples for dashboards, user story examples for mobile apps, user story examples for online shopping, user story examples for banking systems, user stories for loan management systems, user stories for designers and developers, ux user stories examples, technical user story examples, developer story examples, backend user stories examples, jira technical story examples, technical debt user story examples, user stories with acceptance criteria examples, user stories with requirements examples.

User stories in Agile describe the value a user wants from a product without dictating how to create this value. User stories help your team understand what needs to be built, why users need it, and for whom.

Before we look at examples in more specific contexts, here are some general examples that show how user stories can capture the voice and needs of the customer in a variety of scenarios:

• As an avid reader, I want to receive personalized book recommendations based on my reading history, so that I can discover new books that align with my interests.
• As a smart home owner, I want to control all of my smart devices from a single app, so I can easily manage my home’s technology.
• As a restaurant owner, I want to update my menu items in real-time on my website, so that my customers have accurate information.

👋 For a complete overview of user stories check out Parabol’s detailed guide on how to write user stories and try out our user story quiz ! 

Each domain and platform brings unique needs and challenges for your customers. This section looks at user story examples for different contexts – from websites to banking systems.

Here are several user story examples related to common website functionalities like login, registration, and dashboard management.

• As a user, I want an option to stay logged in, so that I don’t have to enter my credentials every time.
• As a user, I want to be able to reset my password if I forget it, so that I can regain access to my account.
• As a user, I want to see an error message if I enter incorrect login details, so that I know when my login attempt has failed.
• As a user, I want to log in via my social media accounts, so that I can quickly access the platform without creating a new account.
• As a new user, I want to choose my own username and password during registration, so that I can personalize my login credentials.
• As a new user, I want to provide my basic information during registration, such as name and date of birth, so that I can personalize my profile.
• As a user, I want to customize my dashboard, so that I can choose which information is most important to me.
• As an admin, I want to see user statistics on my dashboard, so that I can monitor the platform’s usage.
• As a frequent customer, I want to see product recommendations on my dashboard, so that I can discover new products I might like.

Explore these user story examples for the specific needs and preferences of mobile app users.

• As a language learner, I want an offline mode in the language learning app, so I can continue learning without an internet connection.
• As a user of a news app, I want to be able to customize my news feed based on my interests, so that I can quickly find articles I want to read.
• As a user, I want to be able to easily sync my app data across multiple devices, so that I can access my information from anywhere.

A smooth shopping experience starts with a well-crafted user story. Here are three examples of online shoppers’ needs.

• As a customer, I want to track my order, so I can know when to expect delivery.
• As an eco-conscious shopper, I want to see environmental impact details for products, so I can make sustainable choices.
• As an online shopper, I want the ability to save products that I’m interested in for later, so I don’t have to search for them again.

To understand the needs and desires of customers using online banking platforms, let’s look at some user story examples related to banking systems.

• As a customer, I want to receive e-statements for my bank account, so I can reduce paper waste.
• As a user, I want to schedule future payments, so I can ensure my bills are paid on time.
• As a customer, I want to categorize my transactions, so I can better understand and manage my spending habits.

User stories can even address highly specialistic situations. For example, loan management is a critical aspect of banking systems. Here are examples of user stories that address such a specific context:

• As a loan officer, I want to be able to view a customer’s up-to-date credit history, so I can make informed loan decisions.
• As a borrower, I want to calculate my loan eligibility based on my income and credit score, so I know how much I can borrow.
• As a loan processor, I want to be able to track the status of a loan application, so I can manage my work effectively.

User stories can help improve communication between designers, developers, and stakeholders. This section includes examples from user experience (UX) design and software development scenarios.

Below are a few examples highlighting the crucial elements a user looks for when interacting with a product.

• As a user, I want to be able to customize the layout of my dashboard so that I can arrange the information in a way that suits me.
• As a user, I want the form validation to happen in real time so that I can correct any errors as I fill out the form.
• As a user, I want to be able to navigate the site using keyboard shortcuts so that I can perform actions more quickly.

These examples speak to developers’ and system administrators’ needs. Technical user stories are internal facing, focusing on core systems required to run or maintain a product or service.

• As a developer, I want to implement a caching mechanism so that we can reduce page load times.
• As a system administrator, I want to monitor server performance so that I can proactively address any issues.
• As a developer, I want to create an API for our service so that third-party developers can integrate with our platform.
• As a database administrator, I want to back up our data daily so that we can recover information in case of data loss.
• As a developer, I want to create a RESTful API so that our front end can communicate with our back end.
• As a developer, I want to implement an error logging system so that I can troubleshoot issues more effectively.
• As a project manager, I want to integrate Jira with our CI/CD tools so that I can track the progress of builds and deployments.
• As a tester, I want to create bug tickets in Jira directly from our testing tool so that I can streamline the bug-reporting process.
• As a product owner, I want to create custom workflows in Jira so that our process accurately reflects in the tool.
• As a developer, I want to refactor our legacy code so that it’s easier to maintain and extend.
• As a developer, I want to improve our test coverage so that we can catch and fix bugs faster.
• As a developer, I want to replace our custom-built solution with a standard library so that we can reduce complexity and improve reliability.

User stories often go hand-in-hand with acceptance criteria . Acceptance criteria explain the specific requirements a user story should meet before you can mark it as complete. Here are several examples of such pairs.

• As a library member, I want to renew books online, so I can keep them longer without visiting the library. Acceptance criteria: The system should provide the option to renew a book that is not overdue and not reserved by another member. After renewal, the due date should be extended.
• As a restaurant customer, I want to reserve a table online, so I can ensure I have a place to eat at my preferred time. Acceptance criteria: The system should show available times for reservations. After reservation, the customer should receive a confirmation.
• As a music app user, I want to create playlists, so I can organize my favorite songs. Acceptance criteria: The app should provide the option to create a new playlist and add songs to it. Users should be able to name their playlists and view them later.

While user stories and their acceptance criteria address a feature’s ‘what’ and ‘why,’ requirements delve into the ‘how.’ Requirements offer detailed instructions for implementation, often featuring technical descriptions or system interactions, which acceptance criteria usually don’t include. Here are some examples:

• As a banking customer, I want to transfer funds between my accounts, so I can manage my money effectively.

Requirements: The system should allow customers to select two accounts, enter an amount, and execute a transfer. The system should update the account balances immediately.

• As a job seeker, I want to save job listings I’m interested in, so I can apply for them later. Requirements: The job platform should allow users to save job listings to a personal list, which they can view later.
• As a driver, I want to find the fastest route to my destination, so I can save time on my journey. Requirements: The navigation system should provide the shortest time route based on current traffic conditions.

Imitation to innovation: Crafting your own user stories

The true purpose of all these examples is to inspire you on a journey from imitation to innovation in crafting your unique user stories. The nature of your product, the specifics of your user base, and the challenges and opportunities your project presents will require a tailored approach. Use these examples as a starting point into exploring uncharted user story territory.

By crafting your own user stories, you’ll gain a deeper understanding of your users and their needs. You’ll find new and innovative solutions to old problems. And most importantly, you’ll build products that truly serve their intended users.

Try Parabol Sprint Poker For Better Story Point Estimates

Backlog refinement.

The 5 Best Planning Poker Tools for Online Estimation [2023]

Agile , Backlog Refinement · 9 min read

Backlog Refinement · 8 min read

Writing User Stories: Detailed Guide for Agile Teams (+ Templates)

12 Agile Estimation Techniques to Try With your Team

Backlog Refinement · 18 min read

How to Create Better Story Point Estimates

Backlog Refinement · 7 min read

How to Measure Sprint Velocity in Agile

Backlog Refinement · 11 min read

Fibonacci Agile Estimation: What Is It and Why Does it Work?

Backlog Refinement · 5 min read

New: Sprint Poker Estimation

Backlog Refinement , New Features · 6 min read

How to Prioritize the Backlog When Everything is Important

• Product Management
• Product Roadmap
• Team Alignment
• Idea Management
• Prioritization
• Product Strategy
• Product Development
• Customer Experience
• User Research

Home » How to Write Good User Stories (Examples and Tips)

How to Write Good User Stories (Examples and Tips)

This article covers:

What Are User Stories?

What are the 3 c’s in user stories, use invest to create good user stories, how to write good user stories, what are the good user story examples, how to gather user stories, use cases vs user stories.

User stories are short, simple explanations of a software feature written by someone who desires a new capability. 

User stories articulate how a software feature will provide value to the customer . User stories describe the type of users, what they want, and why. They create a simplified description of a requirement. 

In a product management tool like Chisel , you can record user stories on index cards, post-it notes, or with the influx of SaaS . 

Various stakeholders , such as clients, users, managers, or development team members, can write a user story.

In the agile framework , a user story is the smallest unit of work.  It is an end goal, not a feature, expressed from the user’s perspective. An agile user story aims to articulate how a piece of work will deliver a particular value back to the customer.  

“ Customers ,” in this context, don’t have to be current users in the traditional sense. Instead, they can be internal customers or colleagues within the organization. 

In other words, user stories are a few sentences in simple language that outline the desired outcome. There isn’t much detail, but you add the team’s requirements later once agreed upon. 

A kanban or a scrum is a great way to lay out all potential user stories. In Kanban, teams pull user stories into their backlog and run them through their workflow.

On the other hand, in the scrum, user stories are added to sprints and “ burned down ” throughout a sprint. 

Think of user stories as the building blocks of larger agile frameworks like epics and initiatives . Epics are large work items broken down into stories, while multiple epics are composed of an initiative.

User stories are typically written by a product owner or a business analyst in collaboration with stakeholders, such as customers, end-users, and development team members. 

The product owner is responsible for creating and maintaining the product backlog , which includes user stories, and ensuring that the team is working on the most valuable features that meet the needs of the users and the business. 

The business analyst works with the product owner and stakeholders to gather requirements and translate them into user stories that are specific, actionable, and testable. 

Development team members may also contribute to creating user stories by providing technical expertise and insight into implementation details. 

Ultimately, the goal of user stories is to capture the needs and expectations of users in a way that is easy to understand and prioritize for the development team.

An initial set of user stories is part of the discovery process. The team constantly adds new user stories during agile delivery .

Defining user stories is a convenient way to capture detailed requirements while focusing on user goals. That’s why they can successfully determine the value for your users. 

A good user story consists of three elements called agile three C’s. 

Although you can take this literally, the idea behind the first C – card refers to the user story’s optimal size that can fit on a notecard . 

The card should not contain all information about the requirement. Instead, it must have enough information to plan, identify the need, and remind the team of the overall story. 

This is the format they should follow:

“As a [particular user], I want to [perform this action] so that [I can achieve this goal].”

The focus should be on gathering user stories for each user type. It helps create a set of the most representative user stories possible. Ideally, product users should write user stories.

However, it’s okay if other stakeholders or the product owner write them. You can gather user stories through various user research methods such as interviews, questionnaires, observations, and others.  

Using software for product managers like Chisel , user research is easier and more efficient than ever.

Conversations

Before placing user stories in the sprint, the product owner should ask customers for elaboration and validation. 

These conversations are necessary as a user story may be difficult to interpret. Plus, background knowledge could be essential for implementation.

These conversations allow product owners to inform stakeholders of what’s going on. It also allows everyone to digest information accordingly. 

Conversations can include email, internal chat, or any online tool for your cross-functional team . 

Confirmations

The final C of a user story stands for the acceptance criteria . It confirms that the user story has been implemented correctly and is successfully delivered. 

It would be best if you defined acceptance criteria before development begins. It helps determine when each user story is finished and working as intended. 

These criteria demonstrate a user story’s boundaries . They are a common point of discussion during conversations between the product owner, product manager , and users. 

The best practice is to define this criterion before placing user stories in a sprint .

Importance of the 3 C’s in Creating Effective User Stories

The 3 C’s – Card, Conversation, and Confirmation – are essential to creating compelling user stories. They help to ensure that the user story is clear, concise, testable, and accurately reflects the needs of the user and the business.

This, in turn, helps to ensure that the development team is working on the most valuable features and that the end product meets the user and business needs.

Following are the benefits of 3Cs 

• Clarity: The 3 C’s help to ensure that user stories are clear and concise, which makes it easier for the development team to understand the user’s needs and expectations. This helps reduce misunderstandings and ensure that the end product meets the user’s needs.
• Collaboration: The 3 C’s promote cooperation between the product owner, stakeholders, and development team members. This helps ensure that everyone is on the same page and that the user story accurately reflects the needs of the user and the business.
• Consistency: The 3 C’s help to ensure that user stories are consistent in format and content. This can make it easier to manage the product backlog and ensure that the development team is working on the most valuable features.
• Testability: The 3 C’s help to ensure that user stories are testable and measurable, which makes it easier to determine whether the user story has been successfully implemented and meets the user’s needs.
• Value: The 3 C’s help to ensure that user stories deliver value to the user and the business. This can increase user satisfaction, improve the product’s competitiveness, and generate more revenue for the company.

Interested to know what it takes to write a good User story? Let’s first look at the 6 essential indicators of a good user story

INVEST is the acronym you can use to know if you are on track to writing good user stories. 

Independent

Every agile user story must be independent and should stand on its own.  It helps in prioritizing, also called user story priority .

Also, you can move them to the product backlog if the agile user story is independent. 

When implementing the agile user story format, there’s a collaboration between teams and customers.

This is where the negotiation comes in. You will have to decide on what to implement and what to skip .  

When writing user stories, remember that they must be valuable to the customers. 

You must be able to estimate an agile user story.

If a user story is not estimable, then the scope of that story is not well understood. When estimating agile user stories, you can easily distinguish between high and low-effort stories. 

When writing user stories, know that it must take less effort (days or a few weeks) to implement it. 

Any agile user story that is high in the effort is difficult to estimate and negotiate.

One of the best indicators of writing better user stories is testability . When a customer cannot tell if you have implemented their story, the entire team’s effort may be in vain. 

To avoid this, write the acceptance criteria before implementing the agile user story. 

Now that you know the components of a good user story, let’s move forward! You may know how to write user stories.

But have you ever wondered how to write good user stories? If yes, we will consider how to do so efficiently in no time and even without utilizing paper writing services .

Put Users First

As discussed, a user story describes how a customer employs the product from their perspective. 

You shouldn’t write a user story if you do not know who the users are and why they want this product. 

Do adequate user research first ; otherwise, you will risk speculating.

Discover the Right Stories With Personas

Personas are a great technique to capture your insights about the users and customers. 

Essentially, they are fictional characters based on first-hand knowledge of the target group.

They usually include a name, picture, relevant characteristics, behaviors, attitudes, and overall goal.  You can understand the goal as a benefit a persona wants to achieve. 

You need to ask, “ What functionality should my product provide to meet the personas’ goals? “

Collaborate When Creating Stories

User stories are supposed to be lightweight to allow you to move fast. Think of them as a collaboration tool more than a specification. 

The product owner and the team must discuss these stories together. It will allow you to capture the necessary information, reduce cost, and speed up delivery.  

You can even take this approach and write stories together as part of the backlog grooming process.

That leverages the creativity and knowledge of the team leading to better stories.

Make Sure the Stories Are Simple and Concise

It is ‘ the simpler, the better ‘ regarding user stories. 

Avoid confusing and overly fluffy terms. Don’t forget to use an active voice. Focus on the essential parts and leave out everything else. 

Roman Pichler created a template based on Rachel Davies’ popular template.

As <persona>,

I want <what?>

So that <why?>

Start With Epics

An epic is typically broken into several user stories over time, ensuring to leverage user feedback in early prototypes .

They’re a placeholder and headline for more detailed stories. Think of it as the scope.  

Starting with epics allows you to sketch the functionality without committing to anything specific. It comes in handy when describing new products and features.

Using it, product managers can capture the rough outline while buying time to learn how to address users’ needs. 

Suppose you have multiple disjointed, detailed stories in the product backlog. In that case, you can have an epic organizing them. Thus, epics make your whole process time-efficient.

Refine Your Stories Until They’re Where They Need To Be

Continue to break your epics into smaller, more detailed stories until they are clear, feasible, and testable.  All developers should have a shared understanding of the story’s meaning while not being too big. 

On top of this, there has to be an effective way to determine if the story is complete. 

Include Acceptance Criteria

As you break down your epics into smaller stories, you must have acceptance criteria.

It will complement the narrative allowing you to describe the conditions you must fulfill to complete the story. 

The criteria will make the story testable and enrich it. You can demo and release it to users and stakeholders. A good rule of thumb is five acceptance criteria for detailed stories. 

Use Paper Cards

Initially, user stories were born from extreme programming Moreover, the literature around it talked about story cards rather than user stories. It is because teams captured the stories on paper cards.

There are three benefits to this: 

• Paper cards are cheap and easy to use.
• It leads to collaboration as everyone can take a card and jot down an idea.
• You can group the cards quickly and cleanly visually.
• If you are in the office, it can have a tangible benefit .

Make Sure Stories Are Visible and Accessible

The central role of stories is to communicate information . Therefore, make them visible. 

Having visibility fosters collaboration and transparency, whether in Chisel or physically on walls. It makes it obvious when there are too many stories. 

Don’t Rely Solely on Stories.

Creating a great user experience is more than just having well-crafted user stories. They capture product functionality but compliment them with other techniques.

These techniques include workflow diagrams, storyboards, mockups , or sketches.  Beyond this, they’re not good at capturing technical requirements.

If you need to communicate an architectural element, write a technical story. User stories are great if you want to create a product that is likely to be reused. 

Writing stories may not be necessary if you’re trying to build a prototype quickly.

Remember – user stories enable you to move fast and develop as quickly as possible. 

Here are a few examples of well-written user stories:

• As a customer, I want to save my payment information so that I don’t have to enter it every time I purchase.
• As a manager, I want to view sales data by region to make informed decisions about where to allocate resources.
• As a student, I want to track my progress in a course to see which areas I need to focus on.

These user stories are considered good because they meet the criteria of the 3 C’s – Card, Conversation, and Confirmation. Let’s break down each example:

• Card : This user story is clear and concise, stating the user persona (customer), the action they want to take (save payment information), and the reason for taking that action (to save time entering payment information).
• Conversation : This user story could lead to a conversation about how sales data should be presented, what regions should be included, and how the manager will access the data. This helps clarify the user’s needs and ensure that the end product meets their expectations.
• Confirmation : This user story can be confirmed by creating acceptance criteria that define what it means for a student to be able to track their progress in a course. 

For example, the acceptance criteria include the ability to see which modules have been completed, the percentage of assembled modules, and the ability to mark a module as complete.

To use these examples as a reference, you can analyze them based on the 3 C’s. 

Ask yourself:

• Is the user story clear and concise?
• Does it accurately reflect the needs of the user?
• Could it lead to a productive conversation about how to implement the feature?
• Can it be confirmed with testable acceptance criteria? 

By analyzing these examples, you can better understand what makes a good user story and use that knowledge to create your own user stories.

While writing user stories, don’t forget to note down the methods you can use to gather them.

Following are some ways you can collect user stories:

Through Interviews

Ask relevant questions to a diverse audience will help you know what new features you need to add.

Or, if the product is new, then asking the potential customers open-ended questions will be beneficial. 

Through Observation

Have an eye for details and observe how customers use the product. Such observation can also help you write user stories. 

By Conducting Surveys

Survey with questionnaires related to the user stories. Share it online or in hard copy to derive results. 

Getting your hands on the top product management software to collect customer feedback using pre-built surveys and audience tools is recommended.

Prototyping

Show your agile user story ideas to the teams. Then, open the platform for discussion through PowerPoint presentations. 

Conducting Workshops

Another way of gathering and writing user stories is by brainstorming ideas .

A session with participants discusses as many user stories as possible. It would be best not to assess the ideas while in the workshop.

This way, having a pool of user stories in place becomes more effortless. 

Definition of Use Cases

A use case is a methodology used in software engineering to define and describe how a user or an actor interacts with a system or software application to achieve a specific goal. It typically involves creating a scenario that outlines the user’s steps and the expected outcome. 

The use case describes the system’s behavior and how it responds to various inputs or actions from the user. Use cases can be used to identify requirements, validate design decisions, and ensure that the software system meets the user’s needs.

Now let’s address few confusions and clear them up

Is a user story the same thing as a use case? 

Although they share similarities, user stories and use cases are not interchangeable. However, they both can identify users and describe the goal, but they serve different purposes. 

The differences are as follows: 

Degree of Detail

User stories usually are, and purposefully, vaguer . They provide a simple description of what a feature should help a user do. Thus, it leaves it open to interpretation. 

Use cases cover more ground by showing how the user should interact with the system. They also cover how the system should reciprocate.

They go into more detail about the individual steps in a feature-driven development . 

Sprint Length 

User stories can generally fit into one sprint . They contain features or details small enough to be completed as quickly as possible. A team can even get through multiple user stories in one sprint . 

Use cases tend to cover several sprints, providing an overview of a more extensive functionality. They generally list out each step of a feature’s process. 

The user story is just a line or two of a statement about what the user wants to achieve. You can write that on a simple index card, making them quick and easy to create. 

On the other hand, use cases can take more time to put together. That’s because they detail each step and represent it in a diagram. This makes use cases potentially more helpful in a practical sense for identifying friction points in the process. 

However, you can also do this by combining user stories and flows. It helps map out different screens a user goes through in the process. 

When To Use User Stories or Use Cases?

When faced with which to use – user stories or use cases, it all depends on your team, its size, and your product. 

The rule of thumb to decide is to discuss with all stakeholders in the product to hash out the pros-cons analysis of each mapping. 

At Chisel , we always advocate keeping things agile, but every scenario is different. 

If all else fails, using them together is usually your best bet if done strategically rather than one or the other. Combined, they keep the plain language tone of user stories.

However, it can go into extra detail about system functionalities to satisfy user goals. Some experts even recommend starting with use cases first .

Later, you can move on to user stories at later iterations once the foundation is sound. To break it down, you’d be using use cases to create the fundamental features of the product.

And then, you will use user stories when adding the extra features to speed up further development.

In conclusion, user stories are a vital tool for Agile software development teams to understand the needs and requirements of their end-users. By putting the end-users at the center of the development process, teams can ensure that they are developing software that meets the needs of the people who will use it. 

You are familiar with an agile user story and how to write good user stories. 

Learn about the anatomy of a user story, and you are on the way to writing better user stories.

More like this:

• Best Practices in Agile Methodology
• What is ‘Epic’ in Agile?
• What Is Agile Marketing?
• How to ask Users for Feedback ?
• 9 Best Feedback Management Software
• Most Popular Agile Certifications To Consider
• 7 Best Scrumban Tools to Manage Implementation
• What is Story Splitting? Definition and Techniques
• What are Story Points and How to Estimate them?

Crafting great product requires great tools. Try Chisel today, it's free forever.

Agile User Story Example and Templates

Home Blog Agile Agile User Story Example and Templates

In this article, you will learn about User Stories, 3 C’s of a user story, who writes it, how to write it, how to INVEST in user stories, different types of user stories with examples  and  acceptance criteria .

Also, read more about Power BI Developer Future .

What is a User Story?  

User Story is a tool  in which  requirements are captured in an easy to understand plain  language ,  and  is written from the perspective of an end user.  

“ In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system ”  

In  Agile  software development, user stories are used to express the requirements from an end user perspective.  The format of the user story is:  

• <User>  - is the end-user or the role of the user in the application software – “ As a net banking customer ”  
• <perform an action>  - the action the user is performing on the application software –  “I want to add beneficiary in my account”  
• <I  expect.. >  - outcome, desired value, the user expects out of the action performed –  “so that I can transfer money to the added beneficiary”
• The larger-sized stories are called “Epics” which are then decomposed to “Features” and then further decomposed  to a  “User Story”.   
• Epic example:  As a Bank, I want to provide net banking to customers, so that they can perform various transactions .  
• The above Epic can then be decomposed into multiple features: few examples:  
• As a Bank, I want to provide a funds transfer feature to customers, so that they can transfer funds from  one  account to another account  
• As a Bank, I want to provide an account summary for all the customer’s types of accounts .  
• As a Bank, I want to provide credit card details to customers .  
• Now each feature can be decomposed further into multiple user stories.  

User stories, based on the estimated size,  are  taken for implementation in an iteration. User stories should be granular enough that  they can  be completed within an iteration and cannot be continued in the following iteration. If a story cannot be completed within an iteration, the same should be split logically. User stories are prioritized by the product owner based on business priority and are available at the top of the product backlog. The  best Agile certifications  will provide you immersive, customizable courses on agile methodology by experts.

The d ev team pulls the stories into an iteration backlog and implements them. The Definition of  Done( DOD) for user stories is decided by the team which includes acceptance criteria, and processes that need to be followed like unit testing, regression testing, code review, etc. The story is said to be “done” only when it meets  the  preset   D efinition of  D one.  

Know more about  agile vs traditional project management .

Who Writes User Stories?  

So, whose responsibility is to write user stories in an agile team?   

Generally, the notion  is  that only  the  Product Owner s  should write user stories as they are the one s  who elicit requirements from the stakeholders. However, in practice, any member of an Agile team may write user stories, though the overall responsibility is that of a Product Owner.  The p roduct owner should go through the stories and prioritize  them  in the product backlog. Over the course of an agile project, every team member is encouraged and expected to write user stories.  

Prepare for your interviews with these top Microservices interview questions .

When are User Stories Written?  

Are user stories written at the beginning of the project in a traditional way?   

User stories are written throughout the lifecycle of the project.  At the start of the project, user stories are written in Sprint '0', also called as pre-sprint.  Initially, the product owner elicits the requirements from the  stakeholder  and  they are  stored as EPICS, Features and User Stories in the product backlog.  The requirements in agile software development  are  progressively elaborated and hence the need for writing user stories will arise throughout the project. These are written mainly during the backlog grooming session where the product owner decomposes epics/features into granular stories. The Dev team writes stories along with the product owner during this session  and also   get s  involve d  in  the  3 C’s (the next section describes this).  

“Card”, “Conversation” and “Confirmation” is a model that captures the components of a user story.  This  is  popularly known as  the 3Cs model which  helps in planning and estimating the user stories by the Agile team.  

• "Card"  – denotes  a Post-It  note or physical card, typically  3”x5” in  size, where the important information of a user story is captured. The card should contain enough information (not too less or too  much ) that the team is able to understand  in order  to  plan & estimate the story.  
• “ Conversation ” – this is the conversation that happens between the product owner and the dev team to discuss the story and get into the details. This may also be a conversation with the users of the system. This conversation also brings out the creativity of the dev team and uncovers any unstated needs of the users.  
• “ Confirmation ” – this brings out the acceptance criteria for a story based on the above conversation.  This  criterion  will be used to evaluate the story by the stakeholders when the user story is implemented by the dev team.   

The 3 C’s of the user story generally  unfold  during the backlog grooming session whe n  the dev team and the product owner discuss the stories that need to be groomed. The user stories are written during this time as well on the card by the dev team and product owner. Just enough information is captured in the story that enables the team to  discuss and  get into the details , uncovering  any hidden or explicit information  in the process . The team then negotiates with the product owner and arrives at the acceptance criteria for the user story.    

Next, t he dev team estimate s  the user story with the available information. The conversation continues between the dev team and product owner until a consensus is reached with respect to the details and acceptance criteria and until the team can size the same. This round of conversation may happen again during the iteration/sprint planning session. The dev team then implements the story in an iteration which is reviewed by the product owner or stakeholders at the end of the iteration . They will then  accept the story based on the acceptance criteria defined for the story.  

You can also, check out the blog post on how Agile teams can use the  5 whys root cause analysis  process to identify the main reason for the problem.    

Why Create User Stories?  

What  are the  benefits that a team  will  get by documenting the need of the stakeholders in the form of user stories?  

• It enables t he t eam to understand the requirements from a user perspective .  
• The focus is on the user to provide value to them; the user story clearly describes the expected outcome of every action performed .  
• This  manner  of capturing requirements provides opportunit ies  for the team to collaborate more with the product owner and business users .  
• By having conversations (in 3 Cs), the team  is able to  uncover the hidden requirements and also come up with creativ e solutions.  
• Provides a shared understanding of the requirements to the team  so that  everyone is aware of the outcome/goal of the story and  is  on the same page .  
• User stories help the team to achieve smaller product increment s.  
• User stories are more understandable by all stakeholders (technical/non-technical/business/operations) .  
• User stories help  the  team to implement features in smaller iterations  ranging  from one week to one-month duration s.  
• User stories enable the team for progressive elaboration,  where they can  defer the story until more clarity is obtained .  
• User stories help create transparency of the priorities defined by the product owner and the customer .  
• User stories help the dev elopers , product owner and business  owners to reach a mutual consensus  as they discuss the details and agree on the acceptance criteria . With the help of the user stories tool and CSM or  PMP course , professionals can enhance their career skills in agile project management.
• This helps prioritize the product features by the stakeholders  and also  helps to take  the right  decisions  at the right time .    

Types of User Stories

We can classify user stories into functional and technical types: 

Functional: Normally, a user story is written based on the functional aspects of the application software, while focusing on the user and the value of the functionality provided to the user. Functional stories concentrate on the product features which the customer will be testing at the end of an iteration based on the acceptance criteria defined for the story. 

Technical: Technical stories are written to be able to support the functional stories. Technical stories can be classified as 

• Infrastructure stories: any infrastructure addition/modification that may be required to support the functional story 
• Refactoring: this type of story is written to maintain the code and address technical debts. This can be used for designing and automation needs as well 
• Spikes: stories that require research on architecture and design which may in turn help achieve the functional need of the customer. 

Examples of User Stories  

Let us see some examples of user stories (Epics, Features and User Story) in this section. 

User Story Templates

You can utilize four user story templates available for download to capture new product functionality from the user's perspective and specify your acceptance criteria. Each template presents a distinctive layout that varies in the level of detail you wish to incorporate.

• Simple user story template
• Epic user story template
• Thematic user story template
• SAFe user story template

INVEST in User Stories

This is an acronym for a set of attributes or criteria that helps us to assess the quality of the user story.  If a ny of the attribute s  falls short in a story , it  means  that  the team may want to consider rewriting the user story.  

1. Independent:  User stories should be independent of other stories. There should be no overlap between them. They can however follow one after the other in a sequence , in a way that makes it easy  to schedule and implement them.   

This is one of the challenges  that  the team faces especially when they  have  just started adapting agile ways of working. They may have a story which is dependent on something else which may be done by another team. The team s  may hope that they can run  the two stories  in parallel and by the time the  first team is  done, the dependent team will also complete  their part of the story .   This is not the right way of running user stories, as it can result in a lot of confusion and blame.  

The advantage of having independent stories is  that  there is no blame game across teams .   I t  also  allows to  consider  the dependencies and come up with innovative ways of removing them  to  be come  independent.  

2. Negotiable:  The story should not be written in  so much  detail that it becomes a requirement document. If it is in  too much  detail, it does not give an opportunity for the dev team to have any conversation with the product owner or the business. The story should be written with just enough detail  so that it  paves  the  way to open discussion s  with the product owner or  business , and  helps to elicit  detail s  or come up with creativ e solutions .  By negotiating  on the story with the relevant stakeholders , teams can  come to a common understanding .  

3. Valuable:   The story should be valuable to the customer. It should clearly state why we are doing this? How is it going to produce value to the customer? What value will the customer realize by implementing this story?   

The only reason why user stories should be part of the product backlog is  that they  add value to the customer, right?  

4. Estimable:  The user stories should have sufficient detail for the dev team to understand and estimate them. The conversation in 3 C’s helps the team to uncover the details with the product owner and stakeholders, so that they can size the story. If the story is too big  and  not sizeable ,  then the story should be refined or decomposed further. Whatever information the team may require should be available in the story for them to estimate it. In case there is a part  of the story  where the team  has  to  do research, then a “spike” story may be created while the rest of the story can be estimated and taken for implementation.  

5. Small:  Good user stories should be small.  This does not refer to  the size or number of words written in a story.  A s mall story  is of the right length so that  the implementation team  can  complete the story within an iteration. It should be small enough that the story is “fully delivered” during an iteration. 

A small user story helps the team to develop and test quickly and easily.

6. Testable: A good user story should be testable in order to be “Done”. This is supported by the “Confirmation” in 3 C’s where the team comes up with acceptance criteria for every story after the detailed conversation with the stakeholders. The customer should be clear about what he should test during the review. If he is not clear, then the story is not good enough to be implemented. The team works together in a collaborative way to INVEST in good stories. The team learns to write good user stories as they work together and also proactively think about the values and criteria that are laid out in INVEST.

Transformation of documentation on user requirements in a Functional Requirements Document (FRD) or Software Requirement Specification (SRS) in a traditional project management, towards User Stories in Agile project management, is a massive step. It helps shift the mindset of how teams can understand and collaborate with the customer in a better way, by shifting their focus of implementation towards value that the customer may realize from the story. This shift has worked very well in terms of meeting the requirements and expectations of the customer. KnowledgeHut best project management certification course will help you boost your learning about agile user stories.

Krishnakumar Kuppusamy

Krishnakumar Kuppusamy is one of the highly experienced Agile Coaches and SAFe Program Consultant (SPC 5.0). He has 24+ years of experience in information technology industry handling both traditional and agile projects. He has worked with companies like Citibank (USA) & Polaris Software at various capacities in project & program management. 

He has worked for ANZ and Ford India, coaching multiple Agile teams in their transformational journey. He is also a freelance trainer, conducted trainings in SAFe/PMP/PMI-ACP/ITIL/CBAP for over 2000+ professionals helping them getting certified and excel in their respective areas. 

Avail your free 1:1 mentorship session.

Something went wrong

Upcoming Agile Management Batches & Dates

• [ November 16, 2023 ] Abstract Classes in Python Tutorial (12) Software Development
• [ November 16, 2023 ] Python Tutorial – Inheritance (11) Software Development
• [ November 16, 2023 ] Python Tutorial – Advanced Object Concepts (10) Software Development
• [ November 16, 2023 ] Python Tutorial – Classes and Objects (9) Software Development
• [ November 16, 2023 ] Python Commentary – Tutorial (1.1) Software Development

How to write an agile story?

How to Write an Agile Story: A Comprehensive Guide

Many individuals ask how to write an agile story. In this article, we will provide an answer to this question.

Crafting well-defined user stories is crucial in Scrum or Agile practices. Let’s explore the process of writing an agile story together; while it’s not overly complex, finding the right approach can be challenging at the outset.

How to Write an Agile Story?

To begin, I recommend selecting the appropriate format. The most widely used description is as follows:

As a < type of user >, I want < some goal > so that < some reason >.

Some alternative templates may be covered in future blog posts.

This format is popular because it puts the customer/user at the forefront with the “As” section. This immediately identifies who the request pertains to. Some consider the “so that” part optional if the goal is self-evident.

However, this description alone is insufficient for development. It’s essential to detail the management rules to ensure clarity about customer/user expectations.

Defining the Management Rules

In Agile, it’s recommended to express management rules as simply as possible. Avoid complex sentences, acronyms (unless defined), and technical jargon. It’s critical that all readers can grasp the management rules.

For example, consider an e-commerce website’s user story: “As a customer, I want to add a product to my cart.”

If the stock < 1, the product cannot be added to the cart. However, if stock < 1 but preorders = 1, the product can be added to the cart. …

As you can see, presenting your management rules this way is straightforward.

How to Write an Agile Story for Beginners?

Some teams use the A4 story format as a user story template. It’s a simple way to structure all your user stories, focusing on expressing the management rules clearly. You can read our article about the A4 story format .

Testing Our User Stories

When you only detail the management rules, testing various scenarios might be challenging. Thus, it’s advisable to use a specific language to outline the anticipated outcomes; this language is often referred to as “acceptance tests.” The Gherkin language is commonly used by teams for this purpose.

Here’s an example of an acceptance test written in Gherkin language:

Scenario: Adding a Product to My Cart Given I am on my cart And I have a product with ID “1234” in quantity “1” And the remaining stock for this product is “0” When I add “1” quantity to my product Then my cart will display an error Given I am on my cart And I have a product with ID “1235” in quantity “1” And the remaining stock for this product is “10” When I add “1” quantity to my product Then my product’s quantity will become “2”

With this article, you can establish your own format or use the A4 story format for writing your user stories. The key is to ensure that everyone can comprehensively understand the expected outcomes.

Useful link :  Story A4 (in French)

Be the first to comment

Leave a reply annuler la réponse.

Your email address will not be published.

Save my name, email, and website in this browser for the next time I comment.

© 2016 - 2019 | Myagile Partner - All rights reserved

Talk to our experts

Please fill the form below.

Error: Contact form not found.

Blog / Agile Methodology

How to write a user story in Agile? – With examples & templates

It’s a challenge to figure out the exact wants and needs of the end user and implement that knowledge directly towards the development of your software . That is how user stories came into existence. Writing user stories has been one of the ultimate software design and development solutions to understand end-user requirements. According to Wikipedia , Kent Beck (an American software engineer) first introduced user stories in 1997.

User stories in Agile have grown in popularity in the last two decades due to their capability to understand customers at an in-depth level and for being highly flexible. The requirements of end users keep changing every other day and user stories can be amended according to such needs to improve their contribution to mobile app development .

When merged in the agile framework, creating user stories for your app helps you meet the requirements of a larger target audience. It provides the best way to utilize user stories for your software and app.

Read on to discover more about user stories and the user story template, and to see some examples of user stories.

Contents Table

• 1 What is the Agile Framework?
• 2 What is a User Story in Agile?
• 3 What is a User Story Template?
• 4 Types of User Stories
• 5 Importance of Writing User Stories
• 6 Benefits of User Stories
• 7 Key Aspects of a Good User Story Development
• 8 When are user stories written?
• 9 How to Write User Stories?
• 10 Final Remarks
• 11 Frequently Asked Questions

What is the Agile Framework?

The Agile framework is the management of a project by dividing it into multiple phases to give a fail-fast direction to its development and final results. In simple words, an Agile framework is a specific approach to planning, managing, and executing work. Agile frameworks typically fall into two categories: Frameworks designed for teams, and frameworks designed to help organizations practice Agile at scale, across many teams. Digital.ai’s 15th State of Agile Report states that the number of software development teams adopting the Agile framework has increased by 87% in 2021 compared to 37% in 2020.

What is a User Story in Agile?

A user story is a small unit of work in an Agile workflow. It is a short, written explanation of a particular user’s need and how it can be fulfilled. Every agile user story includes a written sentence or two and, more importantly, sparks a series of conversations about the features and functionality the user story represents. It helps the product manager and development team shift their focus from writing about the software features to discussing the features.

User Stories were created to replace the need for traditional requirements documentation, which took teams forever to write and often handcuffed developers to just one way of doing things from the very start. 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. User stories typically follow a simple template:

As a < type of user >, I want < some goal > so that < some reason >.

User story example:

“As a new telemedicine app user , I want to connect with my doctor on a video call, so that I can quickly get proper consultation whenever I need it and the necessary digital prescription for my condition.”

In short, a user story explains the “Who, What, and Why” of your software end users. That is why writing user stories is an integral part of Agile software development .

Creating user stories helps describe the end-user perspective on the app functionality. Knowing this crucial information helps developers build a user-oriented product. The best part is that you do not need technical knowledge of mobile app development to know how to create user stories. Any individual, startup, or business owner can do it to present their product requirements.

What is a User Story Template?

A user story template is a common format used to write user stories that help you include key pieces of information about that user story.

One particular template, often referred to as “As a… I want to… So That…” is the most commonly recommended aid (often outgrown once past the novice stage) for teams and product owners starting to work with user stories and product backlog items in general:

As a (who wants to accomplish something)

I want to (what they want to accomplish)

So that (why they want to accomplish that thing)

An example:

As a bank customer

I want to withdraw money from an ATM

So that I’m not constrained by opening hours or lines at the teller’s

Scrum in Agile Software Development

Types of User Stories

We can divide user stories into functional and technical types: 

• Functional: Normally, a user story is written on the basis of functional aspects of the application software yet focusing on the user and the value of the functionality provided to the user. Functional stories focus on the product features that the customer will be testing at the end of a repetition based on the acceptance criteria defined for the story. 
• Technical: Technical stories are written to be able to support the functional stories. Technical stories can be classified as 

a) Infrastructure stories: any infrastructure addition/modification that may be required to support the functional story

b) Refactoring: this type of story is written to maintain the code and address technical debts. This can be used for designing and automation needs as well

c) Spikes: stories that require research on architecture and design which may in turn help achieve the functional needs of the customer.

Importance of Writing User Stories

Writing good user stories includes a non-technical approach to provide the right direction for the technical process of software/app development . The agile framework typically includes user stories to emphasize aspects that bring value to the final product.

User stories primarily serve the users. They show what problems users have and which solution they prefer for their problems. Developers can use this information to build a product designed specifically for the end-user needs.

User stories also lead to better product clarity as the team has a story that defines the final goal of the product, which gives them clarity into the creative solutions they will need to apply for every requirement of the end user.

Benefits of User Stories

The initial stages of mobile app development can involve multiple creative ideas but only if you get someone who knows how to write a user story for every functionality, you will be able to finalize one.

And below you can find some benefits of user stories:

• A user story quickly describes what features you need to build and how to build them.
• Individuals with both technical to non-technical backgrounds can understand user stories and implement the required changes collaboratively.
• It helps build software and apps from the user’s perspective.
• User stories help the developers, product owners, and business owners to reach a mutual consensus as they discuss the details and agree on the acceptance criteria. 
• Short agile stories are easy to implement in the development process.
• It gives every team member the same goal to work towards and achieve.
• These stories help create a development strategy that can guarantee satisfactory results both for the user and developers.
• The focus is on the user to provide value to them; the user story clearly describes the expected outcome of every action performed.

Key Aspects of a Good User Story Development

Writing great User Stories always fits the INVEST set of criteria introduced by Bill Wake:

The most straightforward answer to what is a good user story is as simple as the question: simplicity and clarity. Only a Mobile app development company with such skills can create user stories that add value to your project. You’ll be surprised at how effective a sentence or two can be in the context of refining user tasks. Simple user stories say exactly what needs to be said and can be put into play much easier than writing a novel about a menial issue.

Agile user stories are made of three factors that Ron Jeffries named in 2001 with the wonderful combination of card, conversation, and confirmation:

• Card: Written description of the story, used for planning and as a reminder
• Conversation: Conversations about the story that serve to spread out the details of the story
• Confirmation: Tests that convey and document details that can be used to determine after a story is complete.

When are user stories written?

User stories are written all over the Agile project. Generally, a story-writing workshop is held at the start of the agile project. Everyone on the team participates with the aim of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.

Some of these agile user stories will undoubtedly be epics. Epics will later be dissolved into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.

How to Write User Stories?

Analyze the target users and their needs

Identify your target end users to understand the common problems they have that you can solve with your software. Good research will help you create a semi-fictional buyer persona for your end users. Another way to look at it will be to create a buyer persona of your end user to simplify the process.

You can move forward with the solutions the end users expect once you know the common problems they have. For example, which feature do users need? Which functions do they not want yet but would like if available? And which errors can make the user avoid your app altogether? You must provide solutions for such problems to ensure a user-friendly and satisfactory experience.

Figure out why the users want a particular feature and what they hope to gain with it. It will help you figure out how much the users will pay without doubt for the solution you provide and the value the solution brings to them.

You can also conduct interviews with target users, figure out pain points, and ask the right questions. The expert implementation of these three factors will ensure that you create a unique user story design for your software/app development project.

Use personas to discover the right stories

The key to writing a great user story is empathy. Give your “user” a name. Create a proper persona for them. Remember some people who you know from real life and who fit this portrait and try to relate to this target group. Ask yourself what functionality the product should provide to meet their goals.

Find out which features provide value to the users

You have to determine which features provide value and which do not once you figure out the who, what, and why of your end user needs.

Get a better understanding by asking yourself questions like:

• How does a particular feature improve the user-friendly experience of the app?
• How many end users prefer the same functions?
• What kind of feature can motivate them to download the app?
• What features can solve most of the common problems the end users have?

Your team will know the right direction to follow with app development when you create user stories for every essential functionality. This approach helps developers understand the importance of a particular feature and the benefits it will bring to users and businesses.

Create Epics

Write epics that emphasize the key features of your app without mentioning its technical aspects. For example, If you are building a healthcare app where users need the feature to buy prescribed medicine on the app itself, the epic for it would be “Buying medicine online 24/7 with 1-hour delivery”.

You have to create epics for every functionality that you plan to provide. It will help you divide large epics into short descriptions known as user stories.

Write a simple yet informative user story

The user story format must be easy to understand for every team member, end user, and investor/stakeholder.

Here is an example of a user story for creating a food delivery app:

As a food delivery app user, I want a search and filter feature for cuisines/restaurants, so that I can easily find the ones I prefer.

Such a user story format is understandable by anyone like end users, developers, investors, and stakeholders. It provides everyone with the final picture of the direction the development team will choose.

Tip: Use the most basic sentence structure with commonly used words. And do not write any complex words or technical information in it.

Determine acceptance criteria for user stories

The acceptable criteria are the predetermined requirements that help determine the completion and practical application of a user story. These criteria can include technical, non-technical, and performance factors of the software/app.

The acceptance criteria is a stage where developers determine the steps and requirements of the chosen feature to bring the user story to life. They provide the required data to confirm that the story is compatible for testing, estimation, and execution.

Present the user stories for discussion

Discuss the user stories with the development team, investors, and stakeholders. It’s the final step to ensure that everyone involved understands the same goal they have to achieve. The various team members could point out the weak points of the user story and whether a particular user should be a priority or whether it only serves a tiny and inconsequential portion of the target audience.

This discussion will also help the developers determine and present the steps necessary for the final implementation of app and software development user stories. The feedback and perspectives of every team member will also help ensure the practicality of user stories.

Final Remarks

User stories in application development are the guides to creating user-centric software and apps that can generate considerable revenue. Especially since they help developers understand the end-user perspective on app features – information they can use in the initial development stage to ensure a satisfactory product.

Looking for someone that can write great user stories for your app is not an easy task but you can easily find one in an all-in-one software and mobile app development company like Ailoitte. We have a team with the expertise to write impactful user stories for many types of app development projects.

Frequently Asked Questions

User stories are a phase in the Agile methodology that presents “Who, What, and Why” factors about your end users. It explains the end-user perspective on your product. Creating good user stories helps you set a user-centric direction for the development process. It helps ensure a satisfactory final product for the target audience.

User stories in Agile software development present the end-user perspective about the software requirements. It describes who the users are, what they want, and why.

A user story includes three things – Who, What and why. To further describe that, the “who” explains the role the writer plays. The “what” describes a function. The “why” represents its business value.

User stories clearly describe the end-user expectations of a particular product. Developers know the exact direction they need to follow during the development process to meet such requirements.

Yes, user stories will provide a comprehensive guide about app features desired by the end users/target audience and why.  For example, a user story for a mobile app sounds like “As a frequent traveler and dating app user, I want the app to detect and change my location automatically so that I can find the right people near me at any time.”

Ailoitte is one of the industry-leading mobile app development companies with more than 6+ years of experience.

Are you looking for developers?

Select Country

Send me a copy of NDA

Recent Posts:

• Website Design Cost in 2023: Average cost of website design for small business
• How to reduce software maintenance costs in 2023? – Estimation and efforts
• Website Maintenance Cost 2023: How much does it cost to maintain a website?
• iOS App Release Checklist 2023: How to publish an app to the app store?
• How to build AI powered mobile applications with OpenAI API?
• Top 10 Best Fintech App Startup Ideas to Consider in 2023
• Best Future Business Ideas for Healthcare Startups and Entrepreneurs
• Ultimate Guide to Mobile Application Testing quality assurance checklist 2023
• What are the Best SaaS Business Ideas for 2023?
• How Outsourced IT Services Save Money 2023?: 5 Steps Follow

Share this article:

Most Popular

#Wireframe vs Mockup vs Prototype

Wireframe vs mockup vs prototype: what are the differences.

Many people in the digital design field use the terms ‘wireframe’, ‘prototype,’ and ‘mockup’ interchangeably. When designing a product for …Read More

#App Development

#aws chime and reactjs, how to use aws chime and reactjs to create a video calling poc.

The use of video calling technologies has surged tremendously as we see remote business and remote socializing becoming increasingly common. …Read More

#Flutter vs React Native

Flutter vs react native comparison: which is better flutter or react native in 2023.

Do you plan on using React Native or Flutter? With over 7.5 billion mobile users worldwide, creating mobile apps requires …Read More

Have an idea? Let's catch up

We are the name behind digital products that get funded, generate millions in revenue, products that get funded.

Recognised By:

** We will ensure that your data is not used for spamming.

Project Launched

Happy Clients

Countries Served

Returning client base

• You are here:
• Agile Business Consortium
• DSDM Project Framework

Chapter 15: Requirements and user stories

Previous chapter: 14 People, Teams and Interactions

15 Requirements and user stories

15.1 introduction.

The importance of a well understood, prioritised and agreed set of requirements is self-evident. However, the attempt to define a full and detailed set of requirements too early in a project often proves to be counterproductive, restrictive and wasteful. It is not possible to define all of the detailed requirements at the outset of a long project. The business environment changes as time progresses; new requirements and opportunities present themselves. As the project progresses, the team understand more about the business need. Defining detailed requirements too early means either needing to change the specification later, which wastes the original work, or delivering to the originally-specified requirements and subsequently failing to adequately satisfy the business need. DSDM acknowledges this dilemma and proposes a better way of working. DSDM advises the capture of requirements at a high level, early in the project. Further detail is gradually elicited as the project progresses, deliberately leaving the finer details as late as practicable, i.e. until the Evolutionary Development and the Timeboxes.  

15.2 What is a Requirement?

At its simplest, a requirement is a service, function or feature that a user needs. Requirements can be functions, constraints, business rules or other elements that must be present to meet the need of the intended users.

If the product to be delivered is a custom-built car, the requirements defining this would be more feature-based: √ A means of propulsion √ A maintainable steering capability √ A comfortable place to sit However, it should be noted that the following are not requirements, but solutions: X An engine X A steering wheel X Bucket seats DSDM projects aim to state requirements in a manner which avoids tying them to a particular solution for as long as possible. This is because more flexibility can be retained in how a solution is eventually provided if requirements are expressed as what needs to be achieved, rather than how they will be met from a technical point of view, e.g. “a means of propulsion”, rather than “an engine”. A solution expressed too early may become a constraint on what can be achieved within time and budget.   

15.2.1 Categories of requirement

The success of any solution is the product of two aspects:

• what it does (functionality, features)
• how well it performs against defined parameters (non-functional attributes, acceptance criteria, service levels)

15.2.1.1 Functional Requirements (FRs)

Functional requirements express function or feature and define  what  is required, e.g.

• Visit customer site
• Obtain conference venue

The requirements do not state  how  a solution will be physically achieved.

• Drive to customer site is one possible solution. However, fly to customer site or travel by train to customer site are potential alternative solutions which may be worth consideration
• Build conference centre is one possible solution. Hire a hotel room is an alternative solution Stating requirements early in the project as what rather than how allows room for flexibility and innovation later.

15.2.1.2 Non-functional Requirements (NFRs)

Non-functional Requirements define how well, or to what level a solution needs to behave. They describe solution attributes such as security, reliability, maintainability, availability (and many other “...ilities”), performance and response time, e.g.

• responding within 2 seconds
• being available 24 hours per day, every day

These NFRs may be:

• All customer facing functionality must carry the company logo
• All customer-facing functionality must respond within 2 seconds to requests
• Hire conference venue might have NFRs of accessibility, security, and availability

15.3 User Stories

15.3.1 What is a User Story?

A User Story is a requirement expressed from the perspective of an end-user goal. User Stories may also be referred to as Epics, Themes or features but all follow the same format.

A User Story is really just a well-expressed requirement. The User Story format has become the most popular way of expressing requirements in Agile for a number of reasons:

• It focuses on the viewpoint of a role who will use or be impacted by the solution
• It defines the requirement in language that has meaning for that role
• It helps to clarify the true reason for the requirement
• It helps to define high level requirements without necessarily going into low level detail too early

User goals are identified and the business value of each requirement is immediately considered within the user story. User Stories are often deemed to comprise three elements -  the 3C’s

• C onversation
• C onfirmation

15.3.2 User Story format

The format of the User Story is as follows: As a  < role> I need So that These two examples demonstrate User Stories at different levels, but using the same format:

At a project level As a  Marketing Director, I need  to improve customer service So that  we retain our customers.

At a detailed level As an  Investor, I need  to see a summary of my investment accounts, So that  I can decide where to focus my attention. User Stories provide another powerful message. Choosing User Stories to define requirements demonstrates an intention to work collaboratively with the users to discover what they really need. The User Story is brief and intended to be a placeholder for a more detailed discussion later – the Conversation. Much of the detail of User Stories emerges during Timeboxes as part of evolutionary development. High-level User Stories (Epics) are broken down by the Solution Development Team into more detailed User Stories just before development commences on that group of stories. Even then, the User Stories are not intended to be full specifications of the requirements. Fine detail may not need to be written down at all, but may simply be incorporated directly into the solution as part of the work within a Timebox. The user story format helps to ensure that each requirement is captured in a feature-oriented, value oriented way, rather than a solution oriented way. In DSDM projects, User Stories are recorded in the Prioritised Requirements List (PRL). This is the equivalent of a Product Backlog in other Agile approaches.  

15.3.3 User Story – the Card

From the PRL, User Stories are often printed onto physical cards, for planning purposes and to help the Solution Development Team monitor progress. The Front of the Card

On the front of the card, the following information is typically displayed:

• A unique “Story Identifier”, usually a number or reference
• A clear, explicit, short name or title
• who is the primary stakeholder (the role that derives business benefit from the story)
• what effect the stakeholder wants the story to have
• what business value the stakeholder will derive from this effect.

The Back of the Card

On the back, the Confirmation area contains:

• Acceptance criteria (the test criteria)

These acceptance criteria define, at a high level, the test criteria which will confirm that this user story is working as required. These are not intended to be the full test scripts, but will be used to expand into the appropriate test scenarios and test scripts during Timeboxes, as necessary. For User Stories at the highest level (sometimes called a project Epic), the acceptance criteria may be used to define the aims of the project using criteria that may be measured after the project has completed (as part of the Benefits Assessment). Project acceptance criteria example:

• Is customer retention improved by 20% within two years?
• Is product range increased by 10% within 5 years?
• Has speed of dispatch improved to within 24 hours of time of order for 99% of in-stock items within 6 months?

User Story Example: Story Identifier:  STK001 Story Name:  Customer Order Description:  As a Customer, I need to place an order so that I can have food delivered to my house. Confirmation:  Acceptance Criteria examples: Functional: - Can I save my order and come back to it later? - Can I change my order before I pay for it? - Can I see a running total of the cost of what I have chosen so far?

Non-functional: availability: - Can I place an order at any time (24 hours per day or 24/7/365)? - Can I view the order at any time (24 hours per day or 24/7/365) up to and including delivery? Non-functional: security: - Are unauthorised persons and other customers prevented from viewing my order?  

15.3.4 Well constructed User Stories

Bill Wake’s INVEST model provides guidance on creating effective User Stories:

A well-written user story is clear, concise and complete. Some simple checks are:

• It does not combine with, overlap nor conflict with other User Stories
• It conforms to organisational and project standards and policies where applicable
• It is traceable back to the business needs expressed in the business case and project objectives
• Where several User Stories relate to the same feature, but for different users, they are cross-referenced to each other

15.4 Requirements Through the DSDM Lifecycle

Projects need:

• A clear project objective
• A statement of the business vision
• A Business Case, agreed with key stakeholders

These form the anchor for the deliberate evolution of the more detailed requirements, iteratively and incrementally, as the project progresses. As the hierarchy of requirements emerges in expanding detail, as the project unfolds, each requirement/User Story can always be traced back to this original vision, as it evolves to meet the real and current business needs.  

15.4.1 Requirements activity during Feasibility

All projects begin with an idea and an expectation of benefits t o give a return on investment. The Business Analyst ensures that the Terms of Reference (which is sometimes vague or unclear) is expanded to provide a clear project objective, a business vision and an outline Business Case . The project vision is clarified and key project objectives are defined. The highest level Epic User Story is the objective of the project. The User Story format can be effectively used to clarify:

• Who needs this? (Do we have the right Business Sponsor?)
• Why do they need it? (What is the key business value expected or needed?)
• What are their expectations? (What are the high-level acceptance criteria?)

The User Story format also helps to identify the key stakeholders with whom to gain agreement for the requirements. In Feasibility, the User Stories (sometimes called Epics or Themes) should constitute a small number of clear statements that are just sufficient to scope the project, to identify whether it is worth proceeding further and to establish likely costs and benefits achievable. DSDM recommends typically less than 10 requirements/User Stories at this point. Non-functional requirements (see above) may also emerge at this point, but these are expected to become clearer and more detailed throughout the project. Some of the more critical ones may be evident from the outset, when the project objective is established, and these need to be captured because they may constrain some of the choices for the project. Even at this high level, User Stories help to focus on the value of what is required.

is a far more effective way of defining what the business needs, than the vague but technically constraining statement:

The user story format helps to bring out the real objectives of a major change. 

15.4.2 Requirements activity during Foundations

During Foundations, more understanding of the requirements is needed, sufficient to clarify the scope of the project, prioritise, estimate and formulate a realistic Delivery Plan.

During Foundations, the high-level Epic or Theme stories established in Feasibility are now broken out into simple User Stories (functional and non-functional). User Stories defined by the end of Foundations in a DSDM project must be specific enough to estimate and small enough to fit into a Timebox (typically 2 – 4 weeks work). This is not the lowest level of breakdown that the project will achieve, but by the end of Foundations User Stories need to be just sufficient to allow for estimates of work to be done and to plan a schedule of Timeboxes for the first Project Increment. At Foundations, User Stories are assembled into a Prioritised Requirements List (PRL). The focus is on describing the business need embodied in each User Story, in a way which does not constrain unnecessarily how the requirement will be achieved. Key non-functional requirements should also be considered and documented during Foundations. It may be difficult or impossible to accommodate such requirements if they are discovered too late in the project. The PRL is baselined at Foundations, to give a clear checkpoint for the set of requirements which was used for planning. In this way, new requirements which emerge during development are clearly identified, and their impact can be assessed.  

15.4.3 Requirements activity during Evolutionary Development

At the outset of each Timebox, the User Stories allocated to that Timebox will be further investigated. The User Stories from the PRL are broken down into more detailed User Stories which are small and clear enough for the team to work from. The detail is only elaborated one Timebox at a time, and thus the complexity of the requirements is managed. Also, the fine detail is only elicited immediately before that element of the solution is created. This avoids time being wasted on developing detail on all areas up front. During Timeboxes, the detailed requirements/User Stories emerge iteratively. The Business Analyst captures the appropriate level of emerging detail within the PRL, where this is not adequately captured within test criteria, prototypes and the Evolving Solution itself. The Business Analyst also works collaboratively with both Solution Development Team and project level roles to help retain the project’s focus on value and priorities. New requirements may emerge which were not identified during Foundations. The Business Analyst facilitates the consideration and impact analysis of these and records their inclusion or otherwise in the project, based on discussions with the Business Ambassador, the rest of the Solution Development Team and/or Business Visionary. The Business Analyst also records details of, and reasons for, any lower priority requirements being de-scoped by team agreement during Evolutionary Development.  

15.5 Conclusion

Requirements evolve and emerge in a DSDM project. Analysis of the detailed requirements is deliberately left as late as is sensible, to avoid unnecessary rework and to manage complexity. Because of this, it is important to obtain agreement to a high-level baselined set of prioritised requirements in the PRL in the early phases of a DSDM project. This gives scope, direction and an appropriate degree of control for the project to evolve the detail whilst allowing change to be embraced and controlled.

Next  chapter: 16  Project Planning and Control

A Product Owner’s Answer to Who Writes User Stories in SAFe

Who writes user stories? 

Based on the Product Owner (PO) Framework article , POs manage and prioritize the team backlog. 

However, this doesn’t directly answer who writes user stories. Does managing and prioritizing include writing stories? Should POs write most or all of the stories? Or should the Agile Teams? 

This question arose when a new PO asked me for ideas for her team. She asked me, “Who writes the stories on your team?”  

Although I gave the new PO an answer about my team, how we worked, and shared who touches stories, this basic question stayed with me. 

Who should write the user stories? 

Here are three potential answers to consider:

• Agile teams should write the user stories
• POs should write the user stories
• It depends on the situation

I’ll explain my reasoning and how I reached for SAFe® guidance considering each possible answer. I also hope you’ll check out the user story-writing resources at the end of this post.

When Agile teams should write the user stories

Lean-Agile leaders have acknowledged a game-changing truth: attempting to ‘manage’ knowledge workers with traditional task management is counterproductive. Management visionary Peter Drucker was one of the first to point this out: “That [knowledge workers] know more about their job than anybody else in the organization is part of the definition of knowledge workers. —SAFe Principle #8 article

To help answer the question of who writes user stories, I turned first to SAFe Principle #8, Unlock the intrinsic motivation of knowledge workers .

The importance of unlocking the intrinsic motivation of knowledge workers was never more apparent to me than when I became a PO. Many of my teammates had more experience with their expertise area and working on our courses than I did. 

This applies across many fields, products, and enterprises: your teammates become experts in what they are doing because most of us want to succeed at work. Thinking about how to help your team individually and collectively find motivation is key, and recognizing team members’ expertise is a crucial way to build trust and respect to lead the work effectively. 

The language in Principle #8 reminds me to define my role and sphere of influence. As a PO, I don’t manage people. However, for my team to produce great learning content, I must care about their knowledge, ideas, experiences, and expertise at each juncture of planning, refining, and iterating on the work they’re doing. 

On my team, Agile teammates usually write user stories. Every teammate has expertise that I don’t have. It would be foolish of me as a PO to write every story when someone else on my team understands the details about accomplishing the work more than I do. 

If I tried to represent their work by defining and writing every story, it could lead to too much rewriting. Rewriting a story is fine as we refine and understand more details and can often be done as a team activity alongside Backlog Refinement, estimation, and even Iteration Planning and it can be streamlined when the right expertise is applied as the story is discussed. 

If I wrote every story, I’d probably have to consult on and rewrite plenty (most) of them. Worse, it could demotivate my teammates if every story was dictated by their PO. 

That said, what I do as my team refines stories is:

1. Provide a strong voice in crafting acceptance criteria

2. Remind the team of our definition of done for work

3. Share who the customer is, and what they want

4. Work with the team (collectively and individually) on what counts as a “minimum viable story” for our backlog. 

You’ll find an example of a minimum viable story at the end of this post.

Why POs should manage, but not always write, user stories

While any team member can write stories at any time, it is the PO’s responsibility to ensure that they are well-formed and aligned with product strategy. The PO clarifies story details, applies user-story voice, ensures ‘INVEST’ characteristics are present, assists with story splitting, defines enablers, and incorporates behavior-driven design (BDD) to ensure stories support continuous value flow. The PO also allows space for ‘local’ stories and spikes that advance product design but are not derived explicitly from ART-level features. —Product Owner article

My second answer to who writes user stories comes from the PO Framework article . 

POs “manage”  the team’s backlog and have content authority. This can mistakenly turn into an expectation that POs write the stories.

POs may write all the stories if: 1. Agile teams are not yet feeling the benefits of transformation. Therefore, they may be slow to embrace the work of writing stories themselves. It can become “another thing to do” or “taking time away from doing the actual work.” 

2. They want to ensure the ART and team backlogs are aligned, and stories in the team’s backlog meet the definition of done and support ART progress. However, if the PO writes every story, they will have little time to perform all the functions POs are otherwise busy with!

For me, it’s important to note the Framework talks about management , not authorship. In fact, the PO article talks about guiding story creation rather than authoring stories.

We don’t find SAFe specifying that POs author the team backlog. What a PO does in order to manage the backlog and guide story creation is both different and deeper than simply writing everything in it:

• Strategizing across the ART to meet ART-level objectives
• Working with Product Managers, Business Owners, and the RTE to deeply understand the matrix of metrics the ART is using, strategic themes, and how both are applied 
• Working closely with Product Managers, who own the ART Backlog, to refine features
• Working closely with the team and stakeholders to decompose features into stories
• Ensuring stories meet user needs and satisfy the team’s definition of done
• Being the go-to person to share decisions the team is making on “how” to complete the work and how it may show up in meeting objectives
• Prioritizing which work to do when so the team can accomplish its goals and contribute to the ART goals while maintaining flow

Here is the guidance I shared with another PO on the idea of the PO writing every story. Becoming a story-writing PO will:

• Create demonstrable work for the PO
• Codify the (damaging) idea that writing stories is a bureaucratic task
• Lead to future disagreements or dissatisfaction about what should be included in the scope of this work
• Set POs up to be the target for those disagreements and dissatisfactions

Here’s what it won’t do. 

It won’t remove the need for teams to plan their work together to achieve flow or avoid rework or misunderstandings about what value is being delivered or how the team is delivering it. For these reasons, I refuse to become a story-writing PO. I insist my team come together to discuss work and decide who is best informed to write a story. I further drive us to consider all of our stories in refinement so there are multiple teammate eyes on it. 

The immediate result of this process with some of my teammates early on was frustration: “I’m so busy that asking me to write about my work instead of doing it feels like you’re wasting my time.” 

Over time, it has borne other, much more nourishing fruit for the team, including: 

• More paired work and team stories
• Better flow and processes to manage flow
• Growth of T-shaped skills
• Improved understanding and thought about customer centricity across the team
• An understanding of each other’s areas of expertise and how work connects on a cross-functional team

If you have teammates who resist writing stories, I recommend you surface this conflict sooner than later and work through it upfront.

The most knowledgeable people write the user stories

I believe the best answer to who writes user stories is the answer to “Who knows the most about this work?” 

Sometimes the answer may be the PO because they’ve gathered the most information. 

In this case, it’s best for the PO to write the story. 

• I have been in an org-wide or ART-level meeting and know about work for every team. This has included tooling updates, requests to prepare specific demos of our work for different kinds of audiences, work around specific milestones, or professional development requests. 
• It is work that came out of my meetings with other teams to service dependencies. 
• It is walk-up work coming from changes or needs that weren’t surfaced before. 
• Talking with an internal or external customer helped me understand a need we had not previously written stories to meet.

It is rare I would write a story for work I am doing. In the above cases, the work would be handled by the team. By writing the story, I am capturing the need as I understand it but not carving the story in stone. 

When thinking of how stories enter the backlog, I find it useful to remember the three Cs of story writing : 

• Conversation
• Confirmation

The C for conversation is most relevant to my mindset on this. The story is a promise our team will discuss this need and decide how to deliver value on it. 

The conversation could include: 

• Refining our understanding of the user and their need
• Revising acceptance criteria
• Discussing who might start the work on it or how the team will deliver the work’s value 

This is the minimum viable story criteria my team uses.

1. Story title : Provide a name that accurately describes the work 2. What : Give a description of the work 3. Activities or tasks : Break down what it will take to complete this work 4. Acceptance criteria : This answers the question, “What can we or our customers do now that we or they could not before?” or “How will we know this is done?” 5. Parent : Connect it to a feature where possible 6. Tags : We note if this is a team story (more than one person tagged) or an individual contributor’s work (a single person tagged) 7. PI and Iteration : When we expect to start and complete this work

I encourage you to use this template as a jumping-off point. 

Look through your backlog and think about who is and could write user stories with the most thoughtful details.

Story-writing resources

Now that I’ve shared my answer to who writes user stories, here are some resources to help write them.

• Stories video playlist
• Creating Your PI Backlog Content blog
• Writing and Splitting Stories guide
• Story Splitting on an Agile Team template
• Facilitator’s Guide to SAFe – Backlog Refinement
• Determine the Team’s Definition of Done template

If you want to receive helpful content like this for your role, don’t forget to set your role in SAFe Studio. This allows us to bring the best content to your SAFe Studio homepage. Set your role in SAFe Studio today.

About Christie Veitch

As a writer and education nerd who loves processes, Christie seeks to move the needle on what learners can do and what educators and trainers will try with learners. She designs and delivers compelling content and training and builds communities of avid fans using these resources as a Scaled Agile, Inc. Product Owner. Connect with Christie on LinkedIn .

Privacy Overview

• All COURSES

Fill in the details to take one step closer to your goal

Tell Us Your Preferred Starting Date

• Advanced Certified Scrum Master
• Agile Scrum Master Certification
• Certified Scrum Master
• Certified Scrum Product Owner
• ICP Agile Certified Coaching
• JIRA Administration
• view All Courses

Master Program

• Agile Master’s Program

Governing Bodies

• Artificial Intelligence Course
• Data Science Course
• Data Science with Python
• Data Science with R
• Deep Learning Course
• Machine Learning
• SAS Certification

• Automation Testing Course with Placement
• Selenium Certification Training
• AWS Solution Architect Associate
• DevOps Certification Training
• DevOps With Guaranteed Interviews*
• Dockers Certification
• Jenkins Certification
• Kubernetes Certification
• Cloud Architect Master’s Program
• Big Data Hadoop Course
• Hadoop Administrator Course
• Certified Associate in Project Management
• Certified Business Analyst Professional
• MS Project Certification
• PgMP Certification
• PMI RMP Certification Training
• PMP® Certification
• PMP Plus Master's Program

• Full Stack Developer Certification Training Course
• Lean Six Sigma Black Belt
• Lean Six Sigma Green Belt
• Lean Six Sigma Master’s Program

How to create an effective Jira user story

Table of Content :

• JIRA User Story
• Importance of Writing Jira User Stories

Best Practices to Write User Story

Who is Responsible for the Development of User Stories?

When do user stories be created.

• How to Create a User Story Template

JIRA USER STORY

User stories in Jira are concise representations of a feature in a developing system described by an individual who needs this new functionality. This person is usually a system user or a customer paying for the solution. It must be informative enough to allow the Jira Certification developer/development team to facilitate analyzing, designing, and creating the specified functionality, feature, or requirement.

In an Agile project Mangement , these stories are primary methods for communicating developer or development team requirements. It is essential that the person charged with recording the specifications can write sufficiently comprehensive and successful user stories. Many teams post stories to the Scrum board and determine which stories and related specifications will be added to the backlog during the sprint planning meeting. However, with software, your team can automate the process.

Jira is a tool for organizing work. It is popular with software developers because it fully supports Agile methodologies, is simple to use, and integrates with software applications. 

These stories are often listed down on sticky notes and copied on an information radiator or scrum board. However, this article aims to use JIRA to maintain records of user stories and how to use the platform to ensure regular communication.

Importance of Writing Jira User Stories 

• They assist the development team in focusing on the end-user. The Jira Certification developer is typically assigned a list of tasks to accomplish, and they require access to a larger picture view of the project. That is what user stories accomplish – they assist the team in remaining focused on resolving significant challenges for real users.
• Jira's user story help maintains project momentum. When a user story is completed, the team can experience a victory and help stabilize the project's momentum.
• Jira learning promotes teamwork. When they identify the ultimate goal, user stories allow team members to work closely, brainstorm, and determine how to develop a feature to achieve that goal.
• Jira Course is highly flexible and customizable to be used in a broad range of environments and processes. The vital component of Jira user stories is that they are described from the user's perspectives, the person who would use the capability. The user may be a customer paying for the system or an internal user.
• Although user stories are generic and do not include precise criteria or specifics, they allow the team to brainstorm potential ideas for achieving the end goals.
• Before writing a User Story step by step, it's important to answer two essential questions: who makes them and when they're made.
• It's time to incorporate a story into your workflow once it's been completed. A story is usually written and reviewed by the project manager , product owner, or project leader.
• The team determines which stories to solve during a sprint or iteration preparation meeting. Teams are now discussing the requirements and functionality associated with each user story. 
• This is a fantastic feature to get professional and imaginative with the story's execution. If these conditions have been agreed upon, they are integrated into the story. Another typical step in this process is to rank the stories according to their complexity or completion period.

As a general rule, Product owners write the majority of stories, as they have to keep the product backlog loaded with tasks. However, take into account that Agile is focused on communication and the sharing of expert opinions.

All team members involved in the business side of the project write stories, as it allows looking at the new application from the standpoint of any potential type of user.

Training Course

2 Days of live virtual training

Typically, a story-writing process is held on the premises at the beginning of the project. They like to prepare in advance to ensure that a project runs smoothly from start to finish.

Later on, developers can use our Scrum User Story listing to generate more accurate estimates and prioritize feature creation for sprints.

User stories are often presented in the following basic sentence structure:

“As a [persona], I [want to], [so that].”

Analyzing this:

• "As a [persona]": For whom are we constructing this?
• "Wants to": We describe their purpose here — not their features.
• "So that": how does your immediate urge to do things that suit your larger picture?

For Jira user story example, user stories could look something like this:

• Like Max, I'd like to invite my friends to this service so that we can all enjoy it together.
• As Sascha, I want to arrange my work in a way that gives me a sense of control.
• As a boss, I want to understand my associates' progress to communicate our successes and shortcomings more effectively.

This structure is not necessary, but it aids in identifying what has been accomplished. When the persona successfully embodies the desired value, the story is complete.

How to Create a User Story Template 

In User Story Template Jira, you can create a new user story by selecting the option to develop a new issue. When choosing the issue type, you must choose Story. The description field can then be used to replace the user story itself. You'll see it on the screen for creating a new issue.

When creating a user story, there are some points to keep in mind:

• User stories must prioritize business value. They are user-centric, focusing on the user's needs, preferences, and specifications. Finally, each user story demonstrates the value that the software you're developing can provide to your users.
• Ensure it is independent. A user story must be able to exist and be meaningful. As such, it must be distinct from all other user stories.
• Additionally, Jira allows you to prioritize user stories, add due dates, allocate assigned user stories to project team members, and provide a story point estimate. If the user story is complete, the team will allocate it to the sprint for implementation.
• A user story is not a description of specific features or a set of specifications. Its purpose is to encourage discussion among project participants about the end goals that a given system must accomplish and the specifications to enable it to achieve those goals.

Conclusion :

Writing user stories is the most effective technique for maintaining standards in an agile project's dynamic ecosystem. Jira includes a multitude of features that assist teams in managing specifications effectively. Users of Jira can connect a user story with advanced tools. At the end of this Jira Training Online, you'll have a clear understanding of agile concepts and methods, as well as extensive hands-on experience with Jira Software. 

StarAgile conducts Jira training online for all the professionals and candidates who want to use Jira in agile software development.

Trending Now

Scrum master certification cost.

Do We Need an Agile Coach

Overview of pmi-acp certification, csm certification vs cspo certification, upcoming jira certification training workshops:, keep reading about.

Related Articles

• PMP Certification Objectives
• Prince2 Cost
• Who Can Do CSM Certification
• Azure Data Factory
• Lean Agile Leadership

We have successfully served:

professionals trained

sucess rate

>4.5 ratings in Google

Drop a Query

Professional Scrum Product Owner

Live Virtual Class, February 28-29, 2024

Class Overview

The  Professional Scrum Product Owner (PSPO)  course is on how to maximize the value of software products and systems. Product Ownership in Scrum requires more than knowledge of how to write user stories or manage a Product Backlog. Professional Scrum Product Owner is a cutting-edge course for Product Owners, Agile product managers and anyone responsible for a software product’s success in turbulent markets.

After the class, students are eligible for the PSPO I assessment certification. Passing the assessment will give you the industry recognized  PSPO I certification . This certification will NEVER expire, and it makes you part of an elite community of PSPO I badge holders.

The PSPO course addresses a significant skill gap in the software development industry that we have seen growing over the last few years. An effective Product Owner is one of the best predictors of product success, but many Product Owners seem to misunderstand the breadth of the role’s responsibilities in delivering a successful product. Maximizing Return on Investment (ROI), optimizing Total Cost of Ownership (TCO), and capitalizing on product Agility are the things a Product Owner is intimately concerned with that the PSPO course focuses on.

Who should attend?

The Professional Scrum Product Owner course is for anyone involved in software development using the Scrum Framework. It is particularly beneficial for those people within an organization accountable for maximizing the value of work done by the Development team, including the Product Owner, Product Manager, and Leadership Team.

Course Topics

On day one, the training focuses on the fundamentals that are essential for understanding and satisfying the role of the Product Owner in the context of product management and Scrum. The course not only provides a greater understanding of the role itself but also gives you a clearer idea of the principles of agile project management by the Product Owner.

You will learn:

• Agile Product Management
• Value-Driven Development
• Scrum Principles & Empiricism
• The Scrum Framework
• Product Backlog Management
• Release Management

Day two stresses on a practical approach to teaching the methodological skills the Product Owner needs for successfully handling a Scrum project.

You will understand more effectively:

• Product build-up
• The relevance of user stories
• Setting and achieving strategic product goals
• Release strategies and planning with Scrum
• Estimating and prioritizing requirements
• Forecasting capability with Scrum
• Product development involving multiple teams
• The total cost of ownership

Class Details

• Website for Sumeet Madan
• Contact Sumeet Madan
• Twitter for Sumeet Madan
• LinkedIn for Sumeet Madan
• Facebook for Sumeet Madan

Delivery Method

Class format, registration, more information.

The 2-day  Professional Scrum Product Owner  course covers the principles and (empirical) process theory underpinning the Scrum Framework, and the role of the Product owner in it. This course is a combination of instruction and team-based exercises, and teaches what is at the heart of the Scrum and Agile movement.

PSPO is the cutting-edge course for effective Product Owners and for anyone working as part of product management team toward maximizing value of work. The course includes advanced thinking for product ownership and behavioral shifts.

Scrum.org maintains the defined curriculum and materials taught by our 160+ Professional Scrum Trainers (PSTs) to assure consistency and quality for students worldwide.

Prerequisites

Attendees will be able to make the most of the class if they:

• Have studied the Scrum Guide (required)
• Have taken the Scrum Open (free online assessment)
• Have taken the Professional Scrum Foundations course, or have experience on or exposure to a Scrum Team
• Possess a general understanding of requirements and requirements decomposition
• Have been on or closely involved with a project that builds or enhances a product
• Want to know more about how Scrum works, how to use it, and how to implement it in an organization

Included within the course costs

• Upon course completion, attendees have the opportunity to take an online assessment of their skills and earn their  Professional Scrum Product Owner I  (PSPO I)
• To reinforce those concepts, if you attend this Scrum.org class and attempt the PSPO I certification assessment within 14 days but do not achieve a score of at least 85% you will be given a 2nd attempt at no cost.
• 40% Discount on PSPO - II
• Official course Material from Scrum.org
• No Renewal Fee for certification

PDU Credits

Students of Scrum.org courses are able to claim Project Management Institute (PMI) PDU credit: 14 PDUs after attending the two-day Professional Scrum Product owner (PSPO). Please note that PMI PDUs are earned for course attendance and not for passing a Scrum.org assessment. Students can claim PDUs under PMI’s "Education courses provided by other third party providers” category. You can claim your PDUs online at https://ccrs.pmi.org.