User stories explained simply: how to divide a product into steps

You may have been told your project will be divided into 'user stories'. The term belongs to developers and hides an idea you already practise when commissioning work: describe a step by what can be verified at the end.

Simply explained, a user story is a construction step described from the future user's perspective, with a list of what can be verified when complete. We say 'step' throughout this article and our product because the English term adds nothing for someone commissioning software.

A step is a sentence and evidence

Take a workshop management tool. 'The customer receives a message when their repair is ready' is a step. It fits a sentence, names the person, and comes with proof of completion: the message leaves at the right time, contains the correct file number, is not sent twice, and is not sent at all if the customer opted out. That evidence list matters. Without it the step is a wish, and project completion becomes a negotiation where everyone defends their reading of the initial sentence.

Why breaking work down changes what you see

A project delivered in one block leaves you without news until everything is shown. Corrections then cost more because the rest was built on top. A divided project returns something verifiable at short intervals. You watch behaviour rather than code: does the message send, the invoice print with correct information, the loyalty discount apply to the right amount? Breakdown is your only way to retain control without reading technical lines, and makes a specification readable to a nonspecialist.

Who divides, builds, and verifies

Three agents share this work without overlapping. Marcel divides the approved specification into steps, each with an evidence list. Amélie builds the step. Félix verifies and has the final word: until evidence passes, the step is not complete. Separation has a reason: writer and checker cannot be the same, or checking mirrors the work. We saw the opposite when everything is green yet wrong.

Order is our strictest rule: tests precede code. Félix first sets what the step must prove, and it fails because nothing exists. Amélie then builds until it passes. Written in this order, a test describes your intention; written afterward, it describes the machine's output and protects you from nothing. We detailed the choice and costs in tests first, imposed on agents.

The oversized-step trap

'Manage customers' is a chapter the size of a quarter. Nobody knows when it ends, so nobody knows whether it is complete. The sign is simple: if you cannot state in three lines what to check on screen, the step is too large and needs splitting. Conversely, a step producing nothing human-observable should not stand alone in a list you approve. The right size lets you say 'Looks good to me' or 'no, this is missing' by observing the result without translation.

The word that remains yours

Every built step returns as a proposal rather than a fait accompli. Say 'Looks good to me' and the next starts. Say no and it returns for correction. The gate exists at every document and step, slowing things slightly and preventing much, for the reasons in 'Looks good to me': human approval.

Divide your project tonight

Write ten sentences starting with a person: customer, secretary, accountant, you. Each states what they do or receive in the future software. Beneath each, write two evidence lines: what you will inspect to say it is right. A resistant sentence identifies the unwritten part of your business that would derail construction later.