How to write a user story

One named person owns the ticket. In an AI-augmented team that is usually the product manager, who owns the context, the acceptance criteria and the signal. Engineers shape the slice and set the size in refinement, and they are the ones who catch a slice that is secretly two. Approval is a separate pair of eyes from whoever wrote it, otherwise the check is not a check. On Tenhaw engagements that ownership sits with two or three senior people under partner oversight from James Rooney, and that is the whole delivery team.

There is no minimum size, only a floor on visibility, so anything that changes what a user can see or do can be a story however small. If it changes nothing user-visible, it is a chapter under a story rather than a story of its own. The signal you have gone too small is three tickets that always ship together and none of which makes sense alone. That is one story that got filleted.

Yes, and you should. Write them and leave them staged in the backlog. They cannot start until the epic is product-approved, and the epic cannot leave Ready for Dev without at least one product-approved story attached, so the writing has to happen first. What you should not do is start building against an epic whose scope or currency share is still moving.

Only if your team still reads it. The template's job was to force the user and the benefit into the ticket. If the title names the user and the change, and the context links the discovery evidence behind it, the template adds a sentence and no information. Keep it if it earns its place in your refinement conversation, drop it if people's eyes slide past it, but do not keep it and then write vague criteria underneath.

A vertical slice crosses every layer it touches, data, service and interface, so shipping it alone changes something a real user can do. "Build the payments API" and "Build the payments screen" are two halves of nothing shippable. Slice instead on one step in the workflow, one type of user, one business-rule variation, one data source out of several, or the happy path with the edge cases as siblings behind it. Then run one test on the slice. If we shipped only this, could a user do something they could not do yesterday? If not, it is a sub-task under a story, not a story of its own.

Three to seven, each one passable or failable by someone who did not write the code. Given, when, then works, and so does a plain checklist; opinions do not. Replace "the page should feel fast" with a number, such as "renders within 500ms at p95 on a 4G profile", and write the negative paths as deliberately as the happy one: empty state, expired data, the dependency timing out. Treat length as a diagnostic too. A story with thirty criteria is an epic wearing a story's ticket type, and the fix is sibling stories, not more criteria.

Yes, but not a financial one. The epic carries the value; the story carries the signal that shows the epic is moving. Write four things on the ticket: the metric, today's baseline, the dashboard or query the number is read from, and the event the build must emit for that number to exist at all. If the instrumentation does not exist yet, make it an acceptance criterion in this story rather than a follow-up nobody schedules. Tenhaw reads its own work the same way, reporting measurable value monthly and recording a month that delivers none as a failed month. A story that ships with no way to read its effect becomes an argument in three months' time.

List every assumption with what you will do if it turns out wrong, one line each. Assume under 5% of sessions hit this, and add pagination if it is higher. Give every open question a named owner and a date, not "the team" and not "soon". Then apply two rules. A question that blocks the build blocks the story leaving the backlog. A question you have chosen to proceed without is a decision, recorded as one, so nobody discovers the gap mid-sprint.

Enough that a developer who missed refinement can build it from the ticket alone, with no follow-up conversation. That means four sentences of context in a fixed order: which user, where in their journey, what happens today, what should happen once this ships. Link the discovery evidence and the parent epic rather than restating them. Then add a line headed "not in this story", naming the sibling tickets that cover the rest. A developer with a gap in front of them fills it generously and the sprint pays for it, which is why an implicit boundary is the fastest route to gold-plating.

No. In The Tenhaw Way, stories are an AI-augmented practice, for teams where a developer writes the code and AI assists. An AI-native team, where the model builds and the developer directs and verifies, stops at the epic and writes an outcome ticket instead: the value share, the key user journeys and the test requirements, handed over whole. Tenhaw publishes both modes in full and free to adopt without hiring anyone, and the line between them falls at exactly this ticket type. Splitting that into stories strips out the context the model needed and pre-empts judgement it can exercise itself. The habit tends to outlive the mode change because the ticket templates and the refinement calendar did not change with it.

About two hours for the ticket itself, plus sizing with the team at refinement. That two hours covers anchoring the story to an approved epic, checking the slice is vertical, four sentences of context, three to seven acceptance criteria, the signal with its baseline, and the assumptions with what you will do if each one is wrong. Tenhaw writes stories to that same two hours inside client teams. If it is taking a day, the slice is too big or the parent epic is still moving and the story keeps chasing it, so the problem is upstream rather than in the writing. Fix that first. Two hours is cheap against a vague ticket that passes review and then fails in testing three weeks later.

Everything this ticket will not deliver, named rather than assumed. Add a line headed "not in this story" listing the sibling tickets that cover the rest. An implicit boundary is the fastest route to gold-plating, because a developer with a gap in front of them fills it generously and the sprint pays for it. Edge cases can sit behind the happy path as siblings when that keeps the slice shippable. Leave out anything with no user-visible change, since that is a chapter under the story rather than a story of its own. Leave the discovery evidence and the epic detail out too, and link both instead, so each claim stays attached to its source.

Title it as a person doing a thing, so "Returning customer pays with a saved card", not "Implement saved-card retrieval". The subject is the user, the verb is observable from outside the codebase, and the whole title runs under about ten words. If the only honest subject you can find is a service or a component, you sliced by layer rather than by the user's journey, so reslice before writing anything else. That makes the title the cheapest diagnostic on the board. A ticket named after a component is usually layer-sliced work, and layer-sliced work ships nothing a user can use, so it cannot be credited with any part of the epic's planned value at validation.

Three things, and it is a check rather than a signature. Is the slice user-visible, can every acceptance criterion be passed or failed by someone else, and does the story belong under this epic rather than a neighbouring one. The approver has to be someone other than the author, or nothing is actually being checked. If you would have to explain the ticket in person for it to make sense, send it back instead of explaining it. Do this early for at least one story per epic, because the epic cannot leave Ready for Dev without product approval, engineering approval and an approved story attached.

In the acceptance criteria, as numbers or named standards, not in a document nobody opens. Performance, resilience and accessibility rules only get tested if a tester can pass or fail them, so write "the saved-card list renders within 500ms at p95 on a 4G profile" instead of "the page should feel fast", and "if the payment provider does not respond within three seconds, the existing card form is shown and no error page appears" instead of a note about graceful degradation. Keep them beside the functional criteria for the same slice. A non-functional rule that lives one layer up in a standards page is a rule nobody was asked to meet on this ticket.

No. A story links to exactly one epic, and that epic links to one outcome that carries a currency target and sits in this quarter's roadmap. If a story looks like it serves two epics, either you sliced across the seam between them and are holding two stories, or the epics themselves overlap and need fixing before more work hangs off them. Product approval checks that link deliberately, because the chain is what lets you say at the end of the quarter which work moved which number. A story hanging off a broken chain is not a filing problem, it is work nobody can defend.

The parts it cannot know. Given a committed epic, a model produces a plausible ticket structure fast, which beats an empty backlog, but it writes criteria that sound testable and that nobody can actually pass or fail, and assumptions stated with a confidence it has no basis for. It does not know today's baseline, the dashboard or query the number is read from, or whether the event the build must emit exists yet. Tenhaw's engineering handbook, open on GitHub, holds 72 rules an agent enforces rather than a human remembers. Treat the draft as a first pass and edit three things by hand before approval: the acceptance criteria, the signal, and each assumption with what you will do if it is wrong.