User Stories

Writing User Stories - Standard, Persona and Technical

A user story is a piece of functionality that either delivers value or is required in order for one or more other stories to deliver value (these are sometimes called Enabler Stories).

An example of a User Story that deliver's value is a story that creates a shopping basket for a website.

An example of an enabler story may be an investigation into multiple component libraries to see which one works best with our product's architecture.

Structure of all User Stories

All user stories have three basic elements:

  1. Title/Description
  2. Acceptance Criteria
  3. Conversation

Title / Description

Borrowing a lot from Kanban, its advised that a User Story Title / Description can be written on one side of a typical Index Card (these come in various sizes, but lets assume a 6"x4" card).

The idea behind this is that this forces the description to be brief. What we are really looking for in the description of the User Story is What is wanted and Why. By keeping it so short we hope to prevent the person writing the User Story to slip into trying to tell The Team How.

Of course, one thing that happens when doing this is that Product Owners start to develop very tiny handwriting! (Just joking!.. sort of...)

What should the Title / Description contain?

It's suggested we include three main elements to the Title / Description.

  • Who will be doing this (WHO)… phrased: AS A xxx
  • What we are being asked to do (WHAT)… phrased: I WANT xxx
  • What is the desired outcome/benefit (WHY)… phrased: SO THAT xxx

For some enabler stories or technical stories we don't need a WHO as this serves no purpose.

Notice the absence of the HOW in the above three. The HOW should be left open for the team to decide as they are the ones doing the work.

Why do we put these three elements in the description?

In short, using this format helps to relay to The Team what the real Outcome of the story is. If The Team understand the context of what's being asked for and why, they may be able to come up with a much better solution that achieves the desired benefit in an entirely unexpected way.

Let me give you an example of a bad user story and a good user story.

Bad User Story

Create a shopping basket page.

Have a [Complete Purchase] button on that page that takes credit card detail.

If payment is cleared by the bank, email the order details to our fulfilment centre.

Good User Story

As a Regular Customer

I want to have a shopping basket

So that I can easily pay for multiple items and only enter my payment details once.

Firstly, these stories are not equivalent. The bad story predicates:

  • the label to use on the button
  • the fact that the basket has to be it's own page
  • that we use a credit card for payments
  • that we get authorisation from a bank
  • that we communicate with our fulfilment centre by email

The good story works in a completely different way. Firstly it tells us the ultimate outcome of the story (I can easily pay for multiple items and only enter my payment details once). Already this stimulates the Team to think about ways of doing this; It adds perspective around who will be using this functionality (in this case a regular customer); thirdly it tells us what it needs (a shopping basket). With the perspective provided with the other two pieces of information The Team may be able to suggest alternatives. Maybe we already have payment details for a regular customer, maybe instead of adding something to a basket we will just order it immediately and provide an enhanced Cancel ability later on. Maybe we don't hold card details, but have a credit system for loyal customers? As the WHO and WHY have been provided the subsequent discussion can be much richer and much more informed.

Acceptance Criteria

In Agile development, we should constantly strive to maximise the amount of work we don't do. We should simplify whenever possible. As this is a constant goal, we may find that we over-simplify to the extent that we actually produce a product increment that has no actual value.

In order to balance this simplification and maximising work not done, we need to provide the criteria that a user story must meet, at the very minimum, in order to be deemed successful. This becomes the list of criteria that must be met in order for that piece of work to be acceptable - i.e. to deliver the desired value.

This acceptance criteria should be able to fit on the back of our User Story index card to encourage brevity and clarity.

A great way of writing Acceptance Criteria is using BDD Scenarios. BDD (Behavioural Driven Development) allow for a clear understanding of what is needed for both development and testing. The basic form of a BDD Scenario has four sections:

  1. Scenario Name
  2. Given <list of assumptions of pre-existing state>
  3. When <actions or behaviours>
  4. Then <expected outcome(s)>

BDD Scenario Example

Scenario 1: User successfully creates a LinkedIn Account

  • GIVEN John is on the LinkedIn Registration page
  • WHEN he enters all required registration fields
  • AND he presses the [Create Account] button
  • THEN a LinkedIn account is created

Note that any of the Given/When/Then clauses can contain Boolean logic if required - an AND clause is included in the WHEN clause in this example. Also note that we are using a Persona in this example (John). We can alternatively use a role

Conversation

A User Story card is not enough. An essential part of a user story is the conversation between the Product Owner and The Team. Discussing the requirements, discussing the acceptance criteria, asking and answering questions as well as discussion possible alternatives.

These conversations, that often happen in the Sprint Refinement meetings, build a shared understanding of what we are trying to achieve and what the expected outcome will be.

Different Ways to Write a User Story Title / Description

Traditional Role based User Story

AS A [Role: e.g. System Administrator]

I WANT All System Privileges of a Leaver to be Removed

SO THAT People who have left the company no longer have access to the system

Persona based User Story

Let's assume we have two Persona's:

Tony - He's our Systems Adminstrator

John - He's a standard user of our product

TONY

WANTS TO Remove All System Privileges of a Leaver

SO THAT People who have left the company no longer have access to the system

Technical / Enabler User Story

When people follow the above story structure for Technical stories blindly they end up with ridiculous stories such as:

AS A Database Server

I WANT a new index on the person table

SO THAT I can find people by date of birth faster

This is ridiculous because Database Servers don't want anything. In and of themselves they don't need to do anything.

If we were to think about this more we could write it from a User perspective:

TONY

WANTS the search for a person by date of birth to be faster

SO THAT he doesn't have to use so much of his time to find a user to cancel their access privileges and he has more time for his other duties

Sometimes there is no user perspective, or adding a User Perspective is so forced it adds little or no value. When this is the case, don't be afraid to change the format of the User Story Title / Description.

E.g.

Let's assume one of our development tools is being deprecated and we need to upgrade to a new version in order that we continue to receive security fixes and other support. You could write such a story like this:

AS A Developer (This adds no value to this story, so we don't need to put this in a purely technical / enabler story)

WE NEED to Upgrade XTool from v1 to v2

SO THAT we continue to receive security patches and other support for this development tool

Although we have removed the WHO, as we are not developing this from a user-perspective, the rest of the user story structure remains the same. We still specify WHAT we need as well as WHY we need it. In this way we can have meaningful conversations as a team around both this story and also possible alternatives that achieve the same or a similar outcome.

One Last Thing...

User Stories are not the only type of story available to you. Another type of story I've recently come across was described by Mike Cohn in his Mountaingoat Software Blog. they are called Job Stories. Please see his blog post here: https://www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories.

The format of a job story is:

WHEN <situation>

I WANT TO <motivation>

SO I CAN <expected outcome>