User Stories

As the most common type of Product Backlog Item, the User Story is central to agile ways of working.

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 (user type)

I can (achieve some goal)

So that (for some reason)

One of the benefits of 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. These large user stories are generally known as epics. Here is an epic 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 sprint, it is split into multiple smaller user stories before it is worked on. The epic above could be split into many stories, including these two:

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.

Credit to Mike Cohn for these examples.

You can read more about how User Stories fit into the hierarchy of information.

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 “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.  You can read more about Story Splitting Techniques.

The Acceptance Criteria is simply a high-level acceptance test that will be true after the agile user story is complete.  You can read more about these in the link above.

Ideally User Stories follow these guidelines:

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

• The 4 Cs

• Just In Time thinking

Do user stories replace a requirements document?

Agile projects, especially Scrum ones, use a product backlog, which is a prioritised 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.  This may be during a refinement session, the sprint planning session or even after this during an activity often referred to as The Three Amigos.

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 artefact the product owner or team desires.

Further Thought

Whilst the template described above is common practise, as with all templatised approaches they risk missing the opportunity to bring the user, their environment, thoughts and needs to the fore.  Back at the start of the adoption of this technique we always used to describe a User Story on a Product Backlog as a "Placeholder for a Conversation".

So long as it helps capture enough information to quickly remind people of details discussed, it describes a system capability from a users perspective (i.e. from the outside, in) and it (along with other artefacts) describes a user in a way that the reader can conjure up an image of this type of user and their needs, you're on the right track. Hence, a template can still provide a useful format in the hands of an expert.