What is a User Story?

When talking about the Agile methodology, the subject of "User Stories" is unavoidable, and yet the definition or the use made of them doesn't always match the original concept.

If you're not familiar with Agile, we covered the subject in a previous article

The origin

In 1998, during a visit to a digital transformation project at Chrysler, Alistair Cockburn, one of the founding fathers of the Agile movement, coined the following phrase: "A user story is a promise for a conversation."

In 1999, Kent Beck introduced (among other things) the concept of "User Story" into practice for project management in his book "Extreme Programming Explained", and over the years the concept has kept evolving, with best practices emerging through experience.

The misconception

If you ask a randomly picked developer to describe the concept of a user story, chances are the answer will be roughly:

"It's the textual description of a software feature from a user's point of view, often 1 to 2 lines on a sticky note."

And while there is a grain of truth in this description, it's a bit like the visible part of the iceberg, because by only using User Stories in the form of a simple card (or a sticky note), we lose a big part of the reason they exist.

The true nature of User Stories

A "User Story" is a tool that allows a software requirement to be defined based on three important pieces of information: "Who?", "What?" and "Why?", or in other words:

• Who is the user who will perform this action?
• What will they be able to do
• What benefit will this action bring them (or another user)

But the concept doesn't stop there. As Alistair Cockburn said, a User Story must "invite conversation," and this is the important concept that sets it apart from older project-tracking tools.

By describing (too) precisely, upfront, a feature that needs to be built, you close off the possibility of (re)discussing the task, both with the different roles involved (developer, architect, UI designer, etc.) and with the client.

In reality, we give ourselves a false sense of certainty by trying to plan everything (which is impossible, since a project lives and evolves even during development), by fixing both the goal (the feature) and, often, the path to get there (the implementation).

The idea behind a User Story is to simply define the context and the goal, but leave the implementation open to discussion among each of the roles involved.

This makes it possible both to draw on the creativity of every role to improve this implementation, and to react more easily in case of a change in the project's direction.

But how can you make sure you get there while keeping the project consistent? Well, thanks to the framework presented right after!

The 3C framework

This framework breaks down the creation of a User Story into three main parts, each starting with the letter C: the Card, the Conversation, and the Confirmation.

The Card

The card is the best-known part of creating a US, and unfortunately it's sometimes the only one people remember.

This step consists of writing, in natural language (10 to 15 words), a software requirement in the form of a feature from the end user's point of view, following this pattern:

"[USER] [ACTION] [BENEFIT]"

Example: "As a seller, I want to post a photo of my item to improve my chances of selling it"

This sentence will serve both as a short description and, more or less, as an identifier when we need to refer to this particular User Story.

The Conversation

As mentioned, this is the major differentiating element compared to other, more traditional task management methods. The discussion part of a User Story must hold an important place and should, ideally, gather as much as possible:

• Exchanges with the client, even including quotes or excerpts from conversations
• Exchanges with the various internal roles
• Files, resources, and as many documents as possible related to the US in question

I want to point out that it's not only up to the Product Owner, Scrum Master, or project manager to take part in the conversation; this space needs to encourage discussion among every branch working on the project!

Because a discussion held alone isn't really a discussion...

The Confirmation

This part must contain all the specifications required by the client to confirm that the completed user story actually meets the requirements.

The project team can also add confirmation elements based on internal quality requirements so that the feature is validated once it's fully functional and the implementation is of good quality.

It is by relying on all the elements present in the confirmation section of each User Story that the Product Owner can decide whether it is definitively validated, or whether it needs to go back into development.

The lifecycle

In practice, a given User Story often goes through 6 different states, which are:

• Pending
• Discussing
• To-Do
• Developing
• Confirming
• Finished

Best practices

There's a mnemonic device to help remember a number of best practices when writing user stories, this trick is the following acronym: INVEST.

I for Independent

A US should be deployable without depending on another user story.

N for Negotiable

Ideally, only the essential part of the user need should be defined, leaving as much room as possible for discussion.

V for Valuable

A US must deliver value to the end user, otherwise it should be reconsidered.

E for Estimable

An estimate should be possible so that the story can be prioritized and placed in a sprint.

S for Small

A US should be short enough to be completed within a few days. If it takes several weeks or months, it needs to be split into several shorter US.

T for Testable

It must be testable using the confirmation criteria established when writing it.

Benefits

The benefits of properly using User Stories in project management include, among others:

• ensuring that attention stays focused on users first
• fostering collaboration between the different roles during the communication phase
• pushing the search for creative solutions for the team in order to save development time and improve quality
• maximizing momentum by keeping user stories short enough and motivating for developers

I hope that thanks to this article you now have a clearer view of User Stories and that you'll be able to implement them more easily in your project management.