Backlog, User Stories and Definition of Done

Overview

The backlog is the living plan for delivery. It turns outcomes, user needs, technical work, security tasks, defects and operational improvements into visible, prioritised work.

Backlog Content

A healthy backlog may include:

• user stories

• research tasks

• design tasks

• technical tasks

• integration tasks

• security tasks

• data tasks

• testing tasks

• documentation tasks

• support tasks

• defects

• technical debt items

• assurance tasks

• supplier tasks

User Story Format

A user story should normally describe the user, the need and the value.

Example:

As a [type of user]
I need [capability or outcome]
So that [benefit or reason]

Good User Stories

Good user stories are:

• grounded in user need

• small enough to deliver

• clear enough to estimate

• testable

• linked to acceptance criteria

• free from unnecessary solution bias

• prioritised

• owned

Acceptance Criteria

Acceptance criteria define what must be true for the work to be accepted.

Good acceptance criteria are:

• objective

• testable

• specific

• understandable

• linked to the story or deliverable

• capable of evidence

Example:

Given an authorised user is viewing the case dashboard
When they filter by status
Then the dashboard only displays cases matching the selected status
And the filter state is clearly visible
And the result count is updated

Definition of Ready

A backlog item is ready when:

• the objective is clear

• the user or stakeholder need is understood

• acceptance criteria are drafted

• dependencies are known

• required inputs are available or planned

• security or data implications are identified

• the team can estimate the work

• the item is small enough for the planned iteration

Definition of Done

A backlog item is done when:

• acceptance criteria are met

• code or artefacts are reviewed where applicable

• tests are complete

• security considerations are addressed

• documentation is updated

• evidence is stored

• stakeholders have reviewed where required

• no critical defects remain

• the item is marked complete in the backlog

Backlog Hygiene

The backlog should be reviewed regularly to remove:

• duplicate items

• stale items

• unclear items

• items outside the Statement of Work

• items with no owner

• items with no visible value

Backlog and Scope Control

Not every backlog item is automatically in scope. The Statement of Work defines the authorised scope. The backlog explains how that scope is delivered.

Where a new backlog item materially changes scope, cost, timeline, risk, acceptance or IP position, it must be assessed through change control.

Traceability

Where appropriate, backlog items should trace to:

• outcome

• user need

• deliverable

• milestone

• acceptance criterion

• risk

• decision

• release