Crafting Compelling User Stories in Agile Environments

“Working with user stories is easy. But telling effective stories can be hard.”  - Roman Pichler

Usually, a product owner or manager formulates or facilitates a cross-team discussion on a user story from an end-user perspective. The goal is to highlight the requirements and desired functionality. But this story is free of any technical jargon. It is assumed whoever is involved should understand what features in the software or product can add value for the user and back to the business. 

So, within the agile framework, user stories form part of the product backlog for effective communication and prioritisation during product development. 

This is the gist of a user story. But anyone with introductory training with product management courses will instantly have questions, including the following. 

• What is the relationship between the product development team and users?
• What are user stories based on?
• How will the user story help in making the product functional?
• What passes to be a user story?
• Why is technical documentation not required?
• How to create a user story?
• Are there any guidelines to follow for crafting a user story?

We cover these areas by starting from basics and helping you create one with expert-recommended tips. 

What is a User Story?

A user story is a simplified documentation describing a feature that the user wants from a product or service. It is an outline, so the development team and business are on the same page to understand what features can provide value. While it is written, it should be good and easy enough to enable verbal communication. 

The product owner determines which task in the backlog holds the most importance. That should be completed first. To do this effectively, it's important to grasp the user's issue, its significance, and the value the user or customer gains from its resolution. This involves actively listening to the user, asking relevant questions, and using these insights to prioritise tasks accordingly.

To simplify this concept further, see how the pioneer of Scrum software development methodology, Mike Cohn, describes in his seminal book, User Stories Applied for Agile Software Development (2004). 

“A user story describes functionality that will be valuable to either a user or purchaser of a system or software.” 

For this to happen, Mike Cohn describes the main features of the user story. 

• A written narrative outlining the story, which aids in planning and serves as a reference point.
• Conversations centred around the story, enriching its details and filling in any gaps.
• Tests designed to convey and record specifics, serving as indicators for when a story meets its completion.

Elements of a User Story

So, what goes in a user story?

Typically, the user story covers the user persona, what they expect from the product, and why they want it. The idea is to put the user at the centre, which can be argued to draw from the Agile values. 

Name of the Story

Throughout the product development process, there are multiple user stories. So keeping a relevant headline or story name is useful. For instance, if users want a feature to help them track their orders, the story name could be ‘Order Tracking’. 

User Role or Persona

A user persona covers characteristics mainly. They can represent the whole of a demographic and their collective motivations will together define what value the feature or functionality will bring. Selecting this role will require who is included and excluded from the story, as well. 

Also, this is an important element that helps in exploring the relationship between the product and the user. In short, it humanises the user. 

What Will the User Gain?

If the user gains, it will bring value to the business. These two go hand-in-hand. And focusing on the user’s gain will immediately shift the focus to simplify the process of crafting a story from their POV. 

The Business Value

Estimating the value of the business is equally important. Specifically, in Agile methodologies, the Fibonacci sequence is used to understand the relative value.
The Fibonacci sequence (numbers like 0, 1, 1, 2, 3, 5, 8, 13, etc.) can help measure how hard or complicated a task might be. The team does not use these numbers to say how valuable the task is for the business directly. Instead, they help to compare how difficult different tasks are in relation to each other. 

For example, a task might be given a '5' if it seems more complicated than one given a '3', but it doesn’t mean the '5' task is more valuable for the business. It just helps the team understand how tough a task might be to complete compared to others. 

User Story Acceptance Criteria 

These are already established and cover the user's requirements and tasks' scope. Authors such as Bill Wakers as highlighted in Cohn’s book describe the qualifying criteria to match the acronym, INVEST. 

Independent

Negotiable

Valuable to users or customers

Estimatable

Small

Testable

Criteria	Description
Independent	Each criterion should stand alone and not rely on others for clarity or completion.
Negotiable	Criteria should remain open to discussion and adaptable to changes or improvements.
Valuable to users or customers	They must signify significant value or benefits for the end-users.
Estimatable	Criteria should be measurable or quantifiable to estimate effort accurately.
Small	Each criterion should be specific and focused, avoiding complexity or vagueness.
Testable	Criteria should be clear and precise, allowing for verification and testing to confirm completion.

For instance, if the user story involves creating a registration form for a website, some acceptance criteria might include:

• The form should collect the user's name, email address, and password.
• All fields must have appropriate validation to ensure correct input.
• After submission, users should receive a confirmation message or email.

Considering User Stories across the Agile Phases

So, when can you make use of the user stories across the Agile phases?

Feasibility Phase

Here, project viability is identified from both business and technical angles. It is essential to write around ten Epics in User Story format. This is to summarise top-level business objectives.

Foundations Phase

During the foundations stage, user stories help establish a strong project base. Creating user stories (with acceptance criteria) as placeholders for future work is important. Generally, teams develop them for non-functional requirements to guide design decisions.

These could be a compilation of a Prioritised Requirements List (PRL/Backlog) as a reference point for managing scope changes.

Delivery Phase

Now, it’s time to work on these stories within timeboxes. They have to be discussed in detail.

And it is important to leave no loose ends.

Follow along with Agile and Scrum courses to better understand these phases of Agile.

Or, check out these videos to enhance your learning on the topic quick.

How to Create User Stories Better

Understand the User

It starts with user research, be it, in UI/UX domain or Agile framework. The point is to engage with users or stakeholders to comprehend their needs, preferences, and pain points.

Then, it is important to create user personas, as mentioned above. This can be done by developing fictional characters representing different user types to capture diverse perspectives.

After gathering requirements, it is time to identify the user's goals. You must define what users aim to achieve through the product or feature. Possibly, list the ways users will interact with the system or application.

Example: Developing a Mobile Banking App

User Research

Engage with users to understand their banking needs, preferences, and challenges with existing apps.

Create User Personas

Develop personas like "Busy Professional Paul" and "Senior Citizen Sarah" to represent diverse user needs.

Identify User Goals and Interactions

Define user goals (e.g., checking balances, transferring funds) and interactions (e.g., logging in, viewing transactions) for the app.

Follow the Time-Tested Connextra User Story Structure

Through the last two decades, Agile development teams have been using the Connextra template. It goes something like this. 

As a <user persona>

I want to perform <some task that the user wants>

So that I can achieve <the goal of satisfying the reason they want a feature and achieving business value>

User Story Example: Connextra Format Applied to Mobile Banking App 

As a Busy Professional Paul,

I want to easily transfer funds between my accounts,

So that I can efficiently manage my finances on-the-go and save time.

As a Senior Citizen Sarah,

I want clear and easily readable text on the app,

So that I can navigate the app comfortably without straining my eyes.

Incorporate the 4C’s to Add More Details

The 4C’s framework is valuable in improving the user story. So the following framework defines how. 

Card

The Card is already determined in the second phase of using the three-sentence format. As it is concise, it gives a high-level view of the user story. The first card has less amount of detail. This is generally referred to as the ‘Epic’ of the user story.

Taking in the same example but a different user story.
Example

As a Busy Professional Paul,

I want to easily transfer funds between my accounts,

So that I can efficiently manage my finances on-the-go and save time.

Conversation

When you engage in discussions, it helps to unravel intricate user needs. Techniques to follow are active listening, asking open-ended questions, and seeking feedback.

Confirmation

Simply put, it verifies whether the implemented solution meets the user story requirements.

Trying to include acceptance criteria, tests, and validation will help validate story completion. 

Example: Ensuring the funds transfer feature allows the user to send money between accounts seamlessly and securely.

Context

Grasping the broader context will help you know the 'why' behind user requirements.

Team dynamics, business goals, and user personas significantly impact story context.

Example: Acknowledging the need for readable text in the app for users like Senior Citizen Sarah due to potential vision concerns demonstrates a context-aware approach in development.

Additional Tips for Writing Better User Stories

Here are some of the best tips, sourced from Roman Pichler. 

• Focus on understanding user needs through research methods like user observation and interviews. Write stories based on real user data.
• Use personas to represent different types of users and help identify important stories. Personas have names, photos, goals that stories can address.
• Start with large "epic" stories and break them down into more detailed, granular stories.
• Keep individual stories simple so they can be easily understood and discussed.
• Include acceptance criteria to further define what would make a story complete.
• Consider writing stories collaboratively with developers for better insight.
• Organise stories visually on index cards or tools like Kanban boards.
• User stories are not a replacement for all technical requirements documentation.
• Experiment with techniques like user stories or use cases to find the best fit for your team.