User stories and acceptance criteria

01The problem

Ashgrove has chosen a supplier who works in two-week sprints, the agile way of building software in small, usable pieces. The supplier's developer looks at your requirements list and asks: "Which of these do I build first? And how will you decide it's finished?"

Agile teams don't work from long specifications. They work from a backlog of small items, each describing something a user needs and why, and each with a clear test of "done". The standard format for those items is the user story, and writing good ones is now a core BA skill in almost every job advert.

02The concept

The user story format

As a [type of user], I want [something], so that [benefit].

• As an accounts officer, I want a list of invoices past their due date, so that I know who to chase each Monday.

The "so that" is the most important part. It tells the team why, which lets them suggest a better way to deliver the benefit, and it lets the product owner prioritise by value.

INVEST: what makes a good story

A story too big to build in a sprint is an epic: split it, usually by user, by step in the process, or by rule ("send reminders" → "first reminder", "second reminder", "don't remind clients on a payment plan").

Acceptance criteria: Given / When / Then

Each story has a few acceptance criteria that define "done", written as scenarios:

• Given a starting situation,
• When something happens,
• Then this is the result.

Write one for the normal case and one for each important exception. They become the tests the team and the business use to accept the story.

03Example

As an accounts officer, I want clients to receive an automatic reminder before their invoice is due, so that fewer invoices go overdue without me phoning anyone.

Acceptance criteria

1. Given an unpaid invoice due on 30 June, when it is 23 June, then the client receives a reminder email showing the invoice number, amount and due date.
2. Given an invoice that was paid on 20 June, when it is 23 June, then no reminder is sent.
3. Given a client on an agreed payment plan, when a reminder would be due, then no reminder is sent, and the invoice appears on the accounts officer's exceptions list.

Criterion 2 catches the embarrassing bug (reminding someone who has paid). Criterion 3 comes straight from a business rule found in lesson 6. Good criteria are where the BA's knowledge of the edge cases pays off.

04Walkthrough

1. Take your Must and Should requirements from lesson 6 and turn each into one or more user stories.
2. Check each against INVEST. Split anything too big: "a billing system" is an epic; "see overdue invoices sorted by days overdue" is a story.
3. Write acceptance criteria for each, covering the normal case and at least one exception.
4. Order the backlog: highest value and lowest risk first. The due date and the overdue list come before automatic reminders, because reminders need them.
5. Review the stories with the accounts officer. If she can't tell from a story what she'll be able to do, rewrite it.

05Practice

06Check your understanding