User Stories in Agile

1. What is a user story?
2. Agile terminologies used in the context of a user story
3. Why create user stories?
4. What are the benefits of writing a good user story?
5. What are the characteristics of a user story?
6. What is an Epic?
7. How is an Epic useful in building a digital product or service?
8. What are the components of a user story?
   8.1) Let’s start with the first one: IDENTIFIER or ID.
   8.2) The second important component of a good user story is the TITLE.
   8.3) The third important component of a well-defined user story is DESCRIPTION.
   8.4) The fourth component is often missed by most called the ACCEPTANCE CRITERIA.
9. What are the acceptance criteria in a user story?
10. How to write acceptance criteria for a user story?
11. What is the INVEST principle in writing a user story?
12. Who writes a user story?
13. When do you write a user story?
14. User story in Agile
15. How do you write a user story?
16. Download free workbook

1. What is a user story?

Imagine you are standing in your favourite coffee shop, and now it’s your turn to place an order. What do you do? You give instructions to your barista in the coffee shop, something like – you want your medium cup coffee in almond milk with cream, no sugar, with cocoa on top.

Similarly, to build a digital product or service, you need to provide instructions to your development team in a certain way. The user story helps you do that. The User Story is a structured and analysed form of product requirements written in a specific syntax, which is understood by everyone in the product team. It provides clarity, removes ambiguity, and forms the basis of work items that need to be done in a given time frame.

The Description of a good user story follows this syntax:

For example, you want to write a user story on the ‘Sort’ feature by price on the product listing page of amazon.co.uk. Then the Description would look like:

As an online shopper on amazon.co.uk

I want the option to see the list of products by price

So that I could see the cheapest product first on the list

At many places, the above definition and syntax are used to define a user story. However, a user story is comprised of four components, and one of the most important components is acceptance criteria, which I will cover in detail below.

2. Agile terminologies used in the context of a user story

In Agile product development lifecycle, you will get to hear the following terminologies for user stories:

• Epic

• User story vs. Epic

• Task of a user story

• Estimation of user stories

• Prioritisation of user stories

• Splitting of user stories

• Merging of user stories

Each of these has been contextually explained in detail below.

3. Why create user stories?

Importance of well-defined user stories:

• User story provides the structure and syntax for the product team to discuss, analyse, and define product requirements that are understood by everyone in the product team

• In the Agile development lifecycle, user stories convey the product requirements to the development team

• The testing team bases its testing scripts on the product requirements given in the user story format.

• The business users refer to the requirements written in user story format to test the product before signing off and GO LIVE

4. What are the benefits of writing a good user story?

If you write a good user story, which has all the correct details including acceptance criteria, then it offers you the following benefits:

1) It saves you time in back & forth discussions and clarifications with your development team

2) It provides you with a higher chance of creating a product with the least bugs

3) If written in a particular style, it makes it easy for the Agile development team to understand and develop a product, thus creating momentum

4) Similar types of user stories will help you deliver quickly, hence increasing the velocity of your development team. (Velocity is an Agile Scrum term to indicate the amount of work done)

5) It also helps you launch your product on time

5. What are the characteristics of a user story?

You must have heard about various terms used in the Agile product development world like epics, tasks, estimation, prioritisation for the user story. Here are a few characteristics of a user story:

1)User story is different from an Epic: An Epic is just a concept, a heading that you have about an idea you want to implement on your digital product or service

2) User story is different from a use case: A use case offers you a different approach, syntax, and template of defining a product requirement. You can use either of these depending upon your team, organisation, and product development team. While use cases were predominantly used to create functional requirements document in waterfall-style projects, a user story is used in projects following Agile.

3) A user story can have multiple tasks: A Task is the actual technical task that your development team does while implementing the user story. A user story can be broken down into multiple tasks

4) User stories can be estimated during the Agile backlog grooming session. The product team sits together to discuss the user story in detail and at the end of that discussion, the development team provides an estimate.

5) User stories are prioritised by the product manager with the help of the product team. This is to decide which items are going to be worked upon next (in the next sprint).

6) User story can be split into multiple user stories in case it is too big or complex

7) Multiple user stories could be merged into a single user story if the need be

8) User story has four important components which when fully detailed make the user story well-defined.

6. What is an Epic?

In a digital product or service, when you are thinking about your user taking the next step in their journey – you think about a concept, an idea – which could be written as a heading. We call that as an EPIC. This could originate from your ideas, or customer feedback, or internal brainstorming sessions. This is an Agile term like a user story.

7. How is an Epic useful in building a digital product or service?

Epics help you discuss the various next steps the customer of your digital product or service is going to take. You discuss the various user journeys, ideas, and features without getting hung-up on the exact details. Also, it helps you sift through your product backlog at a high level, deciding which items to further expand into user stories.

8. What are the components of a user story?

A User story is supposed to have all specific details about a feature that needs to be built on a digital product or service. These are the set of instructions you provide to your Agile development team to build that feature. A well-defined user story has these 4 components:

1) Identifier or ID

2) Title

3) Description

4) Acceptance criteria

The question is – why are these crucial? Why should we focus on getting this right, specifically the Acceptance criteria

8.1) Let’s start with the first one: IDENTIFIER or ID.

For any digital product or service, you will have 100s of user stories – some in past, present, and future. The person-in-charge of writing these user stories, either Business Analyst, Product Owner, or Product Manager, should be able to uniquely identify it with an ID e.g. Prod-147.

These are the 5 benefits of using a Unique Identifier:

• Multiple product teams working on the same product need a way to tag their user stories

• Calling out an ID is easy for discussion rather than saying full description

• An ID is easy for reporting a bug or listing the worked items in the release notes

• Using an Id makes it easy for product management reporting

• ID makes it easy to manage the product backlog in excel or a software

8.2) The second important component of a good user story is the TITLE.

The Title is a short phrase that defines what is the user story about. You need to keep these 3 things in mind:

• It should be clear & concise. E.g. Sort by price on product listing page

• Make sure it is unique to avoid confusion. E.g. if you are using software like JIRA, it will prompt you with an auto-suggest of similar heading and you can change to make it unique

• There is no standard guidance on the length of the title, but imagine this as an Email subject – keep it short and meaningful.

8.3) The third important component of a well-defined user story is DESCRIPTION. 

As mentioned above, this defines what is this user story about. It is written in a simple language, and hence it is useful for non-technical and business stakeholders to define the description of the user stories. How to write the description? Well, there is a specific syntax to write the description. It goes like this:

As a <user>

I want to <take some action>

So that <I could accomplish my goal>

To write the description using that syntax, you need to ask these 3 questions:

• Who is the Actor of this user story? This will help you identify the ‘User’

• What is the Goal of this Actor? This will help you identify ‘What action user wants to take’

• Why does the actor want to do this task? This will help you identify the ‘Reason behind the goal’

8.4) The fourth component is often missed by most called the ACCEPTANCE CRITERIA.

The acceptance criteria hold the details needed to build this user story.

9) What are the acceptance criteria in a user story?

The acceptance criteria are central to defining a user story before giving it to your Agile development team for building that user story. Simply put, a user story is incomplete without this. It has the nuts and bolts, the exact details that will complete your user story, and help the development team build that feature.

You use a specific syntax called BDD – Behaviour Driven Development to write your acceptance criteria. The syntax goes like this:

Given <Actor is somewhere>

When <Actor does something>

Then <An event happens that marks the end-user interaction>

10) How to write acceptance criteria for a user story?

You start by looking at the user journey related to this user story and identify the steps the user takes to start and finish the interaction with this feature.

11) What is the INVEST principle in writing a user story?

You already know that a user story is supposed to have all specific details about a feature that needs to be built on a digital product or service. These are the set of instructions you provide to your Agile development team to build that feature. The INVEST principle is a guideline to help you validate if the user story you have written is a good one. However, it doesn’t tell you HOW to write a user story.

INVEST is an acronym and it stands for:

I= INDEPENDENT: This user story is independent of others. When you pick this user story to develop, you could develop it without any dependency on a future requirement or user story. It’s a complete entity in itself

N= NEGOTIABLE: You define the ‘what’ and not the ‘how’ in the user story. It means that the user story is open to discussion with your product team. This is very important in the case of Agile Scrum teams, where you discuss the implementation of user stories during backlog grooming sessions.

V= VALUABLE: The user story needs to add value to the user of the product

E= ESTIMABLE: When you bring this user story for backlog grooming and estimation, it has enough information for the Agile development team to estimate it

S= SMALL: The user story needs to be small enough in size (estimate) so that the development team can pick this story and complete it in one sprint/development iteration

T= TESTABLE: The user story needs to have acceptance criteria to show how you would test the success of the user story upon the development

12) Who writes a user story?

This totally depends upon the team structure and individual skill level. In many teams, if you just have a product manager or product owner without any business analyst, then it will be their responsibility to write the user story.

In case the team has a business analyst, then the product manager or product owner will collaborate with the business analyst to write these user stories.

The product manager or product owner will discuss the user stories in the backlog grooming sessions with the rest of the product team, but the onus is on them to get it to a level with enough details so that the team can be efficient in these backlog grooming sessions.

13) When do you write a user story?

As a product team, you are constantly running backlog grooming sessions. You discuss the well-written user stories, make any changes as per the discussion, merge them, or split them.

In order to do that, you are continuously writing user stories, preparing for the upcoming backlog grooming sessions, and ultimately the forthcoming Agile development sprint cycle.

One of the important jobs of the product manager/product owner is to stay ahead (at least a sprint) of the development team in terms of providing well-written user stories so that they can get the product built efficiently.

14) User story in Agile

A user story is a very important part of the Agile development lifecycle, where the digital product or service is built based on the user stories provided to the development team. The user story is written by the Agile team member. If you are following Agile Scrum methodology, then you discuss the user stories in the backlog grooming session.

In the backlog grooming session, while discussing the user stories, you add or edit details and provide the estimation to the user story. You also decide if there is a need to split this user story or merge a few user stories together. In the Agile Scrum methodology, these estimated user stories will form part of the sprint backlog. At the end of the sprint, you know which user stories were completed.

It is thus very important to adopt the Agile mindset before you start to write the user story. It enables you to think in an Agile way of building the product iteratively.

15) How do you write a user story?

In Agile development lifecycle, you can follow the following steps to write a user story:

1) Start with your prioritised backlog: Pick the top prioritised user story headings

2) User journey-based thinking: Think through the happy path scenarios and unhappy path scenarios based on the user journey taken by the user of your product

3) Define user story: Write the user stories with acceptance criteria by gathering detail requirements from stakeholders

4) Other artefacts: Use wireframes, visual design, data handling sheets to add clarity and detail to your user story that aids your development team in building that feature

5) Think Agile: Visualise the user journey and features in an iterative fashion, allowing your product to evolve and grow from one version to the next

---

16) Download free workbook

If you want to practise user story writing skills then download this free workbook. We have shared the user story template, best practices and worked-out user story examples of real-life B2C products.

Thanks, Onkar Singh Lohtham

Founder & CPO | Lead Trainer | Digital Skills Mastery

---