- A strong story has four parts: User Story, Background, Requirements, Acceptance Criteria.
- The format keeps intent, context and verifiable done-ness in one place.
- A worked example beats a template. Watch the common pitfalls.
Most user stories are weak because they skip the why. A line that reads "As a user I want to filter by date so that I can find what I'm looking for" is a feature request in disguise. There's nothing in there that lets an estimator, a designer or an engineer make a real decision. The estimator doesn't know how much edge-case behaviour to size in. The designer doesn't know which user. The engineer doesn't know what acceptance looks like. They guess. The story ships late, wrong, or both.
A user story that holds up has four parts, in this order, and uses them all. We've shipped this format across thirty-plus client engagements; it's the house style we use whenever we're inside someone else's Jira. Here's the anatomy, followed by a worked example you can paste straight in.
The four parts of a story.
Section 01 · User Story.
Three lines, in the standard form: As a [persona], I want [action], so that [outcome]. The trick is making each line earn its place.
Persona: specific actors, not "a user". A Series Admin, a show organiser, a Notification Author, a content and delivery owner. Specificity here cascades through the rest of the doc; once you've named who, the requirements and AC get sharper automatically. Action: imperative, scoped to this story. Outcome: the qualitative benefit the persona gets. Not a restatement of the action. The outcome should be a different shape from the action: speed, trust, reach, control, peace of mind, evidence.
If your outcome reads like "so that I can [action] better", you don't have an outcome. You have the action again. Push it.
Section 02 · Background / Problem.
The multi-paragraph context that makes the story make sense as a piece of work. Three short paragraphs is the target.
- Problem today. What's broken, missing, painful, or causing risk. Concrete, not abstract.
- Agreed direction: what the team is going to do about it. Often references a strategic call that's been made.
- Strategic note. Why this matters now. What it unlocks. What's deferred and why. How it relates to other stories.
The Background's job is to give an estimator who's never met the client enough context to size the work without going back to source. Avoid restating the requirements here. That's the next section. Background is for the why; Requirements is for the what.
Section 03 · Requirements.
A numbered list of the rules, decisions and behaviours the story embodies. 5–10 items. Each one is a decision that scopes the work, not a feature bullet. Mix shapes:
- Declarative: "Treat Security Issuers as the issuer catch-all parent group"
- Imperative: "Update grouping logic so that occurrences from regulatory feeds are assigned to Security Issuer"
- Conditional: "Where listing status is confirmed, assign the source to Public Companies"
- Deferred: "Defer delisting edge cases and deeper subgroup handling unless required to complete the migration safely"
Defer rather than omit. If something is out of scope, name it. Estimators look for these. A silent omission means they assume you want it; an explicit defer means they know you don't, this story.
Section 04 · Acceptance Criteria.
A ✅ list of verifiable outcomes. 5–8 items. Each must be:
- Objectively checkable. A reviewer can look at the system and decide true or false.
- Stated as a positive outcome: what's now true, not what the work involved.
- Scoped to this story. Don't repeat AC that belong to a related story.
Replace subjective adjectives ("good UX", "fast", "user-friendly") with measurable conditions: "loads in < 2s", "passes WCAG 2.1 AA contrast", "a new user completes the flow without help text." If it's not checkable, it's not an AC — it's a wish.
A worked example.
Here's a real story in this format, paste-ready for Jira, Linear, Asana or ClickUp. Use it as a template.
User Story
As a show organiser,
I want to upload my show's PDF flyer and supporting documents into a holding area,
so that the Equestrian World team has everything they need to create the show on the platform.
Background / Problem
For this phase, Equestrian World maintains all master data. Show users don't create shows themselves. The organiser hands off source material (flyer PDFs, schedules, course maps, entry forms, prize lists) and the EW team uses it to create the show in the admin console and allocate the submitter to it.
Today there's no formal channel. Show organisers send PDFs by email, drop them in Drive folders, or message the EW team directly. That makes it hard to track which shows are pending setup, easy for documents to get lost, and impossible for the organiser to see where their show is in the queue.
This story creates the in-portal upload surface, the front end of the holding area. The EW-side processing inbox is covered separately under the Admin Console workstream. The upload also unlocks downstream automation: once a flyer is in the system, the user can opt to auto-generate a social post.
Requirements
- Show users can attach files to a show submission. Accepted types are PDF, image, Word and Excel.
- Multiple files per submission, with type tagging from a controlled list: Flyer, Schedule, Course Map, Entry Form, Prize List, Other.
- Files tagged Flyer offer the option to auto-generate a social post (handled in Publish To Social).
- Files can be replaced while the submission is in Submitted or Under Review status.
- File size limits and accepted types are surfaced before the user picks a file.
- Upload progress is visible; confirmation state is shown on success or failure.
- All uploads are virus-scanned and rejected if they fail size, type, or scan checks, with a clear error.
- Files are stored against the parent submission and exposed to EW admins in the processing inbox.
- Upload activity is logged against the submission for audit.
Acceptance Criteria
- A show user can upload one or more files against a new or existing submission.
- Each uploaded file is tagged with a document type from the controlled list.
- Files tagged Flyer surface the social-publishing option.
- Uploads are virus-scanned and rejected with a clear error if they fail.
- Files can be replaced while the submission is in Submitted or Under Review.
- Upload progress is shown during upload and a confirmation appears on success.
- Files appear against the submission in the EW processing inbox.
- All upload events are logged against the submission for audit.
Common pitfalls.
- Generic personas. "As a user" is weak. "As a Series Admin" is strong.
- Restating requirements in the Background. Background is for the why. Requirements is for the what.
- Subjective AC. "The flow feels intuitive" is not testable. "A new user can complete the flow without help text" is.
- Skipping Background. Tempting, but it's what makes the story land for an estimator or stakeholder who wasn't in the room.
- Padding Requirements. If you're at 15+ items, you probably have two stories disguised as one. Split them.
- Action restating outcome. "I want to X so that I can X better" is a smell. Outcome must be qualitatively different.
Where this lands.
A backlog of stories like this is what makes a PO Piece job possible. Refinement happens in fifteen minutes instead of an hour, and engineers can pick up work without asking three questions first. If your team's backlog isn't holding to this standard, The Backlog Set Piece (1–2 weeks, fixed scope) reshapes it. Or take the Diagnostic to see whether you need a PO Piece, a PM Piece, or both.
Next issue: Acceptance Criteria: the contract. What makes one verifiable, and the patterns that hold up under audit.