User Stories | What is a User Story?

Definition

A user story is a simple description used to understand a feature to be made, typically used in Agile work environments; the story of a user. They are meant to be told from the end user’s perspective to contrive the most business value. User stories are a catalyst to replace lengthy requirement documentation used in traditional or waterfall projects with conversations and true understanding. They can be created by any stakeholder, but the Product Owner is typically responsible for continuously refining and prioritising user stories within a team’s backlog to meet the needs of their users. 

The standard way of writing a user story is: As a ______, I want ______, so that _____. 

Example: As an iPhone user, I want my iCalendar to sync with my Google work calendar, so that all of my appointments are in a consolidated view.

Types of team backlog items

To fully understand what a user story is, it’s helpful to know what else exists within the same ecosystem – the team backlog. Whether your team uses Scrum, Kanban or another type of system of work, almost all teams have a backlog of work items that need to get done. User stories are one type of those work items that typically focus on new features or functionality of a product or service. 

Other work items you might find in the backlog include;

• Enabler stories: Work items that support architecture, infrastructure, and compliance. For example, upgrading technology to the latest version to avoid tech debt of incompatibility or lack of support. 
• Bugs: Defects found through testing or using existing functionality. For example, a pop-up on a mobile form doesn’t go away when the user hits ‘Cancel’. This would need to be fixed as a bug. It’s useful to keep track of how many bugs are found per user story to encourage continuous learning and improvement.

A healthy backlog has a balance of prioritised user stories, enabler stories and bugs.

Characteristics of Good User Stories

A commonly used and trusted framework for measuring the quality of agile user stories is the INVEST model. It stands for:

I	Independent – Stories should be self contained, and dependencies between stories should be limited. Removing all unnecessary dependencies and blockers optimises a team’s ability to reprioritise based on the value of the story and come up with solutions creatively. Iterative development is inherent to Agile, so don’t stress about removing ALL dependencies – that’s impossible!
N	Negotiable. Unlike detailed requirements, user stories should be a catalyst to conversation between engineers and stakeholders in order to truly understand the purpose of why the story exists. They should be negotiated and collaboratively investigated within teams to determine whether the feature would actually provide value to the end user.
V	Valuable. Delivering value is at the crux of development, and this is true at the user story level. How a business or stakeholder defines value may vary. Whatever that definition of value is, ensure it’s understood and sustained as you create and review user stories.
E	Estimable. Is the story able to be estimated? If a user story has so many unknowns and complexities that it’s impossible to estimate the scope, it likely needs to be broken down into a smaller or more defined piece of work or have an associated timeboxed spike (see enabler story) to do more research.
S	Small. Typically, user stories should be broken down enough that an engineer can complete it within a predefined cadence such as a sprint, iteration or other agreed upon Service Level Expectation (SLE) on Kanban teams. Usually this is somewhere between less than a day to two weeks. This helps provide users with incremental value added to shorten feedback loops and adjust quickly if necessary.
T	Testable. To be successful, a story needs an objective way to be tested. The testing should prove or disprove that the acceptance criteria has been met. For this reason, acceptance criteria should be made before the team begins development to ensure the intended value of the story has been accomplished, not just that the new functionality works and doesn’t break things.

Elements of User Stories

Title: The title of a user story should capture the business value it’s providing in the simplest way possible.

Description: Just like any other type of story, good user stories need a who, a what, and a why. This is where the formula for user stories comes in: As a ____, I want _____, so that _____.” Sometimes user story descriptions can end here, but stakeholders and Product Owners need to use their judgement to ensure the story is understood by the team and meets their Definition of Ready. This might also include attachments such as reports or mockups. 

This format and style purposely only refers to the who, what and why (the value) and not the HOW. This gives the development team the ability to self organise and freedom to determine the best approach to implementing the story.

Acceptance criteria: Acceptance criteria are a list of objective statements that can be tested to ensure the user story has been completed successfully. A format for writing acceptance criteria that is consistent with writing the description of user stories is: “Given _____, when I ____, then I _____”. 

Example

User Story: As an iPhone user, I want my iCalendar to sync with my Google work calendar, so that all of my appointments are in a consolidated view could be

Acceptance Criterion: Given that I have navigated to the iCal app on my iPhone, when I scroll to a new date, then I can view appointments that were entered from my Google Calendar app. 

Acceptance criteria can also be written as a bulleted list of the different elements a user should be able to see or do in order to accept the outlined User Story as complete and successful. Regardless of the format, acceptance criteria should be testable, concise, understandable and come from a user’s perspective. 

One of the core Agile values is “Working software over comprehensive documentation”.

Agile teams value documentation, however, working software is more valuable and the only true measure of progress or success. This is why user stories only have a few key elements and should focus on what will achieve the user’s desire, not on technical details or prescribed approaches to development.

How to split user stories

User stories should be small enough to complete within an iteration or less, however, splitting a story can be harder than you think! Mike Cohn, founder of Scrum Alliance and Mountain Goat Software, has consolidated the many techniques into a 5 step system that can apply to any user story. This is called the SPIDR approach. It stands for spikes, paths, interfaces, data and rules.

S	Spikes. A spike is research time devoted to learning new information about a large story. This can help make remaining work more manageable or uncover ways to break the story into smaller pieces of work.
P	Paths. If the story covers multiple paths from a user’s perspective, consider splitting each path into its own story and prioritise which path is the most important. This can be done by drawing a flowchart of the steps of the story. Each step or each sequence could become a smaller story.
I	Interfaces. You may want to consider splitting a story that covers multiple screens, browsers types, versions or hardware. Additionally, start with the simplest interface (minimum viable product) on a single interface before adding styles and “nice to have” functionality”.
D	Data. Can the story be split by the type of data it supports? For example, multiple stories could be created to support valid data, invalid data or frequency of types of data expected to be needed in the story.
R	Rules. Sometimes, business rules or technology standards need to be supported within a story. This provides an opportunity to split a story into smaller initial development to shorten the feedback loop with users, while another split story will add specific business rules or tech standards back in.

Conclusion

Writing user stories can be challenging. The best way to improve your user story writing and understanding is through experience, but understanding the foundations of what user stories are, characteristics of a good user story, elements of user stories and how to split them will help set you and your team up for success. Aginic has Agile experts and coaches to help you through your Agile journey. Get in touch today!

Experience is the best way to increase user story understanding and improve your user story writing skills. To gain valuable experience, it’s essential to know the foundation of what user stories are and what characteristics and elements they should contain. This will help set your team up for success.