User Stories: How To Write – a Guide for Product Owner, Scrum Master and Everyone

Many people are asking about How To create better User Stories. As such, User Stories represent one of the main building blocks of Agile. User Stories could be seen as an elegant way of combining business requirements with your functional requirements, providing end-to-end traceability for customer needs and benefits, down to the feature level.  Also, User Stories (written properly with Acceptance Criteria) allow for pro-active Risk and Quality Management, leading to reduction in time-to-market and cost factors of your product. however, it's appropriate to make a step back to the Epic level first, before we start talking about nighty-gritty of writing User Stories.

In no way, I'm suggesting that User Stories could be a remedy for all problems. It would be similar to saying that well-written requirements document will solve everything. Yet, well articulated and understood requirements serve as a pre-requisite for healthy project delivery and dramatically increase success rate of delivery value on time, if not faster.

I would also like to thank you SCRUMstudy, whose well-structured materials I used to safe a lot of my time with preparing this. Having said that, the below has been reworked to include and reflect real-life references.  

Create Epics and Personas

In SCRUM terminology, an Epic is defined as a big, unrefined User Story, usually too large to be delivered in a single Sprint. Epics are mostly created during the Initiate stage of an Agile project, at which stage most User Stories are understood at a high level of functionality, and requirements are vaguely defined based on the Project Vision. Epics would need to be broken down into smaller User Stories at some point before estimation and  delivery.

These big, unrefined User Stories are included in the Prioritised Product Backlog. Once these Epics come up for review in an upcoming Sprint, they are then broken down into smaller, more granular User Stories. These User Stories are generally simple, short, and easy to implement blocks of tasks to be completed in one Sprint.

The Product Owner is responsible for creating User Stories. Generally, the Product Owner creates those, but sometime they are developed by the Scrum team in consultation with the Product Owner. the Collaboration in Scrum team favours the Product Owner involving the team in writing User Stories. The Product Owner gets the benefits of the team members' expertise; the team members become more familiar with business values and develop a greater sense of ownership of the project delivery. However, the Product Owner is responsible to ensure that all business requirements are included and understood by the team.

The Scrum Team can make use of a number of controls and tools to create efficient Epics. Various other factors should be considered as well, such as approved and unapproved Changes, Laws and Regulations, Contract terms, Policies and Procedures, and so forth. Some of the approaches used in this process are User Group Workshops and Interviews, Focus Group meetings and Questionaries. While creating Epics, it is important to identify risks, so the Team might use a number of Risk Management techniques as well.

 Another output of this process are Personas. Which are supplementary to Epics in that they help the team better understand users and their requirements. Personas are highly detailed fictional characters that represent different segments of end users and other stakeholders who may not directly use the end product. Based on the persona, a Product Owner can prioritise features and create a Product Backlog. It is Product Owner responsibility to ensure that Personas are identified and described.

Like in Product Marketing, identifying and describing a Persona involves assigning a fictional name and a picture, age, gender, education, environment, interests, goals, and other specific characteristics of the Persona's customer segment.

Grooming requirements in the form of Epics/User Stories is an ongoing effort. At the beginning of the project, the Product Owner works with the customer to gather requirements, that are high level and not clearly defined at that stage. The Epics will be created and refined later in the project. Gaps in functionality will be identified after a few iterations, and User Stories will be written to fill these gaps.

A Product Owner can use several techniques to collect Epics/User Stories. Some of them are:

  • User Interviews
  • User Group Meetings
  • Questionnaires
  • Observation
  • UX Workshops (see Rapid Experimentation from Servian)

Create User Stories

User Stories remove the need for detailed documentation of customer requirements. They are written in business domain language. The primary responsibility for creating User Stories lies with the Product Owner. User Stories are compact descriptions of business functionality from a user's point of view.

A typical User Story uses this structure:

"As a Persona>,

I want/need functionality>,

so that Business Benefit>."

This format forces stakeholders to identify the Persona and the business reason for each functionality, and link those together in one, concise requirement statement.

Here is an example of an Epic-sized User Story:

"As a power user, I want administrative permissions, so that I can perform administrative functions."

User Stories are iterative in nature and might have to be written constantly throughout the project live cycle. When a User Story is considered too large for a Scrum team to complete in a  single Sprint, it is considered an Epic, and should be broken down into smaller User Stories before it can be worked on. The Epic above could be split into dozens including the following:

"As a power user, I want administrative permissions, so that I can specify whether the user has read, write, or modify permissions."

"As a power user, I want administrative permissions, so that I can add or remove new users."

Details are added to User Stories in two ways:

  1. By splitting Epics into smaller User Stories
  2. By introducing Acceptance Criteria

Related User Stories can be associated as "themes". A theme is a collection of related User Stories. Themes can contain User Stories from one or more Epics. 

Criteria for a Good User Story

I like the below memory shortcut for this:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable


Independent of other user stories, and internal and external dependencies. This is not always possible. In such situations, one of the solutions is to combine dependent stories into one, independent story. If you cannot find a way to split or don't want to combine, then you may write conditional estimates on a card. E.g. 2 story points, if dependency implemented.

Negotiable - as having a flexibility in scope to allow negotiation. Also, specifying the intentions, allowing for flexible implementation.

Valuable - having clear value for Product Owner to include in the Product Backlog. Some features could be background, technical capabilities, with limited value for end user.

Estimable - Scrum team should always be in position to estimate the story, based on the story's narrative, acceptance criteria, and any additional notes. Main reasons for a team not being able to estimate would be: Lack of Information (Solution: to communicate and add more details), Lack of Previous Practical Experience  (Solution: Spike), or To Big of a Story (Solution: split)

Small - a small User Story is easier to estimate, track and complete within one Sprint. Some rules of thumb: "Small is less than 20% of sprint velocity", "Don't accept User Stories that are bigger than 2 points"...

Testable - a User Story's Acceptable Criteria must be clearly defined, otherwise it becomes difficult to judge whether story is Done. When the customer struggles to clearly define how a feature should be tested, it may indicate an issue. Potentially, testing could be automated all together.

User Story VS Use Case

The main differences between a User Story and a Use Case are in the perspective and the intent, which affects the level of captured details.

Use Cases focus on the interactions between a system and one or more actors, where an actor can be a user or another system. Use Cases describe a process and its steps  in sufficient detail, so they can be understood on their own. That includes usually a call-and-response format.

On the other hand, the User Story focuses on the user's value and is much lighter than a Use Case. It provides just enough detail so that a reader can understand the overall functionality. User Story is written is everyday language to make sure the User Story is understandable by both developers and customers. In contrast to the Use Case, a User Story is a reminder to have a conversation with your customer.

Acceptance Criteria

Along with the User Story, the Product Owner defines what they consider Acceptance Criteria, which are the success criteria for each User Story from Product Owner (and as such, from Persona's) perspective.

Acceptance Criteria should explicitly outline the conditions that User Story must satisfy.


"As an online grocery shopper I should be able to add/delete multiple items from the cart before I check-out so that I can be certain that I am meeting my budget"

The acceptance criteria:

  1. The shopping cart has to automatically update when a user adds/deletes an item
  2. A user can successfully delete/modify the contents of the cart from a single window
  3. Cart items are saved until the user clears its contents or logs out from the website without saving

Den is a Founding Partner and a Director in Fastlane Solutions. He has over 15 years of experience, and is a well-recognised professional within business and technical communities in Australia and abroad. He has a deep industry background in Financial Services and Banking, Telco, and Retail. His expertise covers complex Program Delivery, Technology Leadership, Agile Management, and B2B Enterprise Information Management, down to the solution level.