Writing User Stories

Study Materials

Writing user stories & acceptance criteria

The craft behind the Delivery Backlog page — how to write a story that's actually ready to build, not just a sentence with 'As a user' at the front.

Structure: As a / I want / so that

As a [role]

Names a specific user or persona — not 'as a user,' which hides who actually benefits and why.

I want [capability]

States the capability itself, described from the user's point of view, not the system's.

so that [benefit]

The reason this matters — the part most often dropped, and the part that lets anyone question whether the story is worth building at all.

INVEST — what makes a story ready

I

Independent

Can be built and delivered without waiting on another unfinished story.

N

Negotiable

A statement of intent, not a locked spec — the how is worked out with engineering.

V

Valuable

Delivers something a real user or the business actually cares about, on its own.

E

Estimable

The team has enough clarity to size it — if they can't estimate it, it's not ready.

S

Small

Fits in a single sprint / iteration — if it doesn't, split it.

T

Testable

Has acceptance criteria specific enough that everyone agrees when it's done.

Weak vs. strong — a worked example

A treasury transfer story

Weak

“As a user, I want to transfer money so that I can move funds.”

  • "A user" — which user? A treasury manager, an approver, an auditor?
  • "Transfer money" — between what? Any two accounts, or only approved entities?
  • "So that I can move funds" restates the want — it isn't a real reason.
  • No acceptance criteria at all — impossible to know when it's actually done.
Strong

“As a corporate treasury manager, I want to transfer tokenised USD deposits between approved group entities so that I can move liquidity outside traditional cut-off times.”

Acceptance criteria

  • Only authorised users can initiate transfers
  • Beneficiary must be an approved entity
  • Sanctions and entitlement checks must complete before settlement
  • Transfer is either atomically settled or fully rejected
  • Receipt includes timestamp, unique transaction ID and audit events
  • Balances and reports update after settlement

This exact story (DST-202) appears in full on the Delivery Backlog page, alongside 23 others written the same way.

Two acceptance-criteria formats

Given / When / Then (Gherkin)

Best for a story with clear triggers and branching outcomes — especially anything with a pass/fail or success/exception path.

Given a transfer has been initiated and screening is pending
When the sanctions screening returns a true match
Then the transfer is blocked and a compliance case is raised

Plain checklist

Best for a story that's a flat list of independent conditions, none of which depend on a specific trigger sequence.

- Statement covers a selectable date range and entity
- Export available in a standard machine-readable format
- Statement totals match platform ledger balances

Common mistakes

Writing acceptance criteria that describe implementation, not outcome

"Uses a Redis cache for the balance lookup" tells the team how, not what to verify — acceptance criteria should survive a completely different implementation.

A story too big to estimate confidently

If the team's estimate ranges from 3 points to 20 depending on who's asked, the story is actually several stories wearing a trench coat — split it.

Acceptance criteria that aren't actually testable

"The system should be fast" isn't testable. "Settlement completes in under 60 seconds" is.

Losing the 'so that' clause

Without it, nobody reviewing the backlog later can tell whether the story is still worth building, or was solving a problem that no longer exists.

Confusing a story with a task

"Update the database schema" is a task, not a story — it has no user-visible value on its own. It probably belongs inside a story as a hidden implementation step, not as its own backlog item.