User Stories Explained: Who, when, where, what and why?

An exploration of Agile User Stories: what are they, why do we have them, when and where do we use them?

We’ll examine several different formats and examples and look at how they differ from traditional requirements.

What are User Stories?

User Stories are the Agile equivalent of requirements*. They are simple plain-English sentences that aim to capture the essence of a request in a tight focused format so that everyone – technical and non-technical – understands what is needed and why.

An example of a User Story for an online shopping system which could have inspired a solution like Amazon’s 1-click:

AS A busy shopper wanting just one item
WHEN I’ve chosen what to buy
I WANT to quickly place my order
SO THAT I can save time

The principal purpose is to enable further collaboration and communication. A User Story is a placeholder – a starting point only – and is not by itself a comprehensive description of what is needed or how to build.

The key goal in writing a well-formed User Stories is for everyone to be clear and agree what the request says. Poorly constructed stories are ambiguous and open to misinterpretation.

What's wrong with traditional requirements?

Traditional requirements are simple statements of WHAT, often disconnected from any context about WHO needs this feature or WHY. These statements are also often solutions rather than problem statements, risking a premature jump to solve the user’s problem without exploring other, potentially better, solutions.

There are actually 5 different important questions that requests need to answer, from the 5 Ws:

WHO wants this?

WHEN and WHERE do they want it?

WHAT do they want?

WHY do they want this? (underlying need)

Traditional requirements also come in monolithic forms as part of huge unwieldy requirements specifications, intended for sequential waterfall-style implementation. Agile User Stories are designed to be independent of each other and hence can be implemented separately, enabling an incremental and iterative approach to building solutions.

Another User Story example, this time for a customer of personal loans business:

AS A customer with several loans
WHEN I get onto the system
I WANT to see the outstanding loan balances
SO THAT I know how much I still owe

Now that we understand what the user is asking for and why, we can choose to do exactly as requested or to come up with a better solution that may satisfy other requests too – for example not only showing the balances but showing a graphical burn-down of when the loan will be paid off.

What are the common User Story formats?

User Stories come in different formats that address different set of the 5 Ws. They all have a simple sentence structure which is a guide to ensure that appropriate questions are explored when capturing a request.

Four different User Story formats

Clockwise from top left:
1) The “standard” and most common format you will see,
2) After Chris Matts who believes the WHY should be emphasised first to focus on value,
3) My favoured format because it includes all the Ws,
4) ‘Job’ Stories which focus on a situation involving a user.

Let’s explore the meaning of each of the Ws with User Stories:

WHO – This is the user, or user role representing a specific type of user, which may be a sub-category (e.g. the “busy” “shopper” “wanting just one item” are all sub-categories in our example above)

WHERE/WHEN – This is the situation, or point in the flow of the product/service, when this user story applies (e.g. the “I’ve chosen what to buy” describes and distinguishes where the user is in the flow)

WHAT – This is what the user wants to happen; their immediate goal or desire. As far as possible, this should not be written in terms of a specific solution, avoiding implementation details (e.g. the “to quickly place my order” captures what the user wants without specifying how)

WHY – This is why the user wants this outcome. It is a deeper look at the benefit and the need that this request will fulfill (e.g. the “I can save time” explains why speed is so important and links back to the WHO)

User Stories should attempt to avoid HOW. That’s because HOW is an implementation detail – there are many possible HOWs for each requirement. HOWs are better captured with Strategy Stories (more on this in a separate blog). There are blurry boundaries here, however, sometimes it’s only possible to state the WHAT in terms of an existing HOW – what’s important is to understand the WHY and consider the alternative solutions carefully.

Whichever format you use, what is most important isn’t the format itself but the questions you ask when constructing the story. It is these questions that lead to good quality User Stories that capture the essence of requirements. Having them in this format forces you to ask them.

How are User Stories used?

Because of their simple plain-English structure, User Stories become the lingua franca of Agile – they are the glue that enables everyone involved to keep track of what is going on. Any stakeholder can enquire as to the status of a story – has it been designed, implemented, tested, released to users?

A team building an Agile solution using User Stories will create a whole set of artefacts based on the User Stories, including Acceptance Criteria, Scenarios, Tests, Design materials and much much more. These are created as they explore implementing the solution and may well involve other techniques such as Behaviour-Driven Development.

This process is often referred to as Card, Collaboration, Confirmation. We capture the User Story on a physical index card then we use this to collaborate with others inside and outside the delivery team to figure out how to build a good solution, using the questions the story prompts to confirm what is required.

User Stories might seem complicated to some and people do sometimes get hung up on different formats. That’s really just noise, so long as you are asking the right questions and clearly capturing the results.

Good luck with your adventures with User Stories!

*NB: The word ‘requirement’ is a misnomer. It conflates a request with its own prioritisation – implying that anything that is a ‘requirement’ must be implemented. A better word is ‘request’ which is what I’ve used here. There may be many User Story requests that are not implemented because they are low priority.

Posted in Agile, Demand and tagged .

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>