User stories: how we turn your wishes into buildable work
A wish list is not a plan. User stories describe who needs what and why, small enough to build in days. The format and what makes a good one.
The short answer
A wish list is not a plan, and a hundred-page requirements document is a plan nobody reads. Between them sits the user story: one sentence that says who needs what and why, small enough to build and test in days, with acceptance criteria written before the work starts. “As a receptionist, I want to see today’s bookings on one screen so that I can greet patients by name.” That sentence tells the builder who to design for, what to build and how to judge whether it works. A project is a backlog of such stories, ordered by value, detailed only for the stage ahead, written with the people who will use the software rather than about them.
The anatomy of a story
| Part | What it contains | Example |
|---|---|---|
| Who | The role, specifically | As a receptionist |
| What | The capability, not the screen design | I want to see today’s bookings on one screen |
| Why | The outcome that makes it worth building | so that I can greet patients by name and prepare their file |
| Acceptance criteria | Checks that must pass to be done | Shows all bookings for today across all practitioners; updates within a minute of a change; works on the front desk tablet; a cancelled booking is marked, not removed |
| Size | Small enough for days, not weeks | If it is bigger, it is several stories |
Writing stories together
- Sit with the people who do the work, not their manager, and ask what they need to do and what gets in the way.
- Turn each need into who, what, why, in their words.
- Ask “how would you know it works?” and write the answers as acceptance criteria.
- Split anything that would take more than a few days into smaller stories that each deliver something.
- Order by value: which stories, done first, make the software useful soonest.
- Detail the next stage’s stories fully; keep the rest as headlines in the backlog.
What stories replace
The requirements document that took two months, was signed, and was wrong by the time building began. The feature list with no purpose attached. The meeting in month three where everyone discovers they imagined something different. Stories keep the purpose next to every piece of work, are refined as their turn comes, and are tested against criteria the users wrote. They are lighter than the document and far more accurate, because they are written close to the work and close to the time.
What this means for you
Expect your software project to be planned as a backlog of user stories, written with your people, each with acceptance criteria agreed before the build, detailed a stage at a time and ordered by value. It is how wishes become buildable work without a document nobody reads, and how you know, story by story, that what is delivered is what was needed.
Frequently asked questions
Why not just give the developer a list of features?
Because a feature list says what, not who or why, and the who and why are what decide the details. "A dashboard" could mean fifty things; "as the owner, I want to see this week's revenue against last week's on my phone each morning so that I know whether to call the sales team" can be built, tested and judged. Stories keep the purpose attached to the work.
How many stories does a project have?
Dozens to a few hundred, depending on size, but only the next stage's stories need to be detailed. The rest are headlines in a backlog, ordered by value, refined as their turn approaches. Detailing everything up front produces a document that is out of date before the build starts.
Who writes the acceptance criteria?
Together: the person who will use the feature says what must be true for it to work for them; the builder adds the edge cases and technical checks. Written before the build, the criteria are the test and the definition of done. Written after, they are a negotiation.