User story format and intent
A user story is a short description of a change that delivers value to a specific person (or system actor). In Scrum, stories help a team plan and execute a Sprint by focusing on outcomes rather than tasks. A good story is small enough to complete within a Sprint, clear enough to discuss, and testable through acceptance criteria.
The common format
Use the classic template to keep stories user-centered:
As a <type of user>, I want <some goal> so that <some benefit>.How to interpret each part:
- As a… identifies who benefits (or who needs the capability). If there are multiple user types, pick the one whose needs drive the behavior.
- I want… describes the capability in plain language. Avoid implementation details (for example, “add a table” or “create an API endpoint”).
- So that… states the value. This helps the team make trade-offs and spot unnecessary scope.
Intent: what a story is (and is not)
- A story is a promise to talk. The sentence is a placeholder for a conversation about behavior, constraints, and examples.
- A story is not a task list. Tasks may be created later to implement the story, but the story itself describes user-visible behavior.
- A story is not a requirement document. Keep it short; put details into acceptance criteria and examples.
Beginner method: craft a story in 5 steps
- Name the user. Choose one primary user type (e.g., “registered shopper”).
- State the goal. What are they trying to accomplish (e.g., “save an address”)?
- State the value. Why does it matter (e.g., “checkout faster next time”)?
- Remove solution words. Replace “add a dropdown” with “choose from saved addresses.”
- Check Sprint-sized scope. If it sounds like a feature area, it likely needs splitting.
Example (good starting point):
As a registered shopper, I want to save a delivery address so that I can check out faster next time.Example (too solution-focused):
- Listen to the audio with the screen off.
- Earn a certificate upon completion.
- Over 5000 courses for you to explore!
Download the app
As a shopper, I want a new address table in the database so that addresses are stored.The second one describes implementation, not user value. The team may still build a table, but that is not the story.
Writing acceptance criteria using concrete examples
Acceptance criteria describe the conditions that must be true for the story to be considered done. They reduce ambiguity and help the team test the behavior. For beginners, the easiest way to write acceptance criteria is to use concrete examples and observable outcomes.
Two practical formats
1) Bullet conditions (simple and fast):
- What must happen
- What must not happen
- Any limits or rules
2) Given/When/Then (behavior-focused):
Given <context> When <action> Then <expected result>Given/When/Then is helpful when behavior depends on state (logged in vs. logged out, empty cart vs. full cart).
Step-by-step: turn a story into acceptance criteria
- List the main user action. What does the user do?
- List the visible result. What does the user see/receive?
- List key rules. Validation, limits, permissions, calculations.
- Add at least one negative case. What happens when input is invalid or a constraint is violated?
- Add one example with real values. Concrete data makes hidden assumptions visible.
Concrete example: “Save a delivery address”
User story:
As a registered shopper, I want to save a delivery address so that I can check out faster next time.Acceptance criteria (Given/When/Then):
Given I am logged in When I submit a new delivery address Then the address is saved and appears in my saved addresses list.Given I am logged in When I save an address with missing required fields Then I see which fields are required and the address is not saved.Given I have saved addresses When I start checkout Then I can select one of my saved addresses for delivery.
Concrete data example:
- Required fields: Full name, Street, City, Postal code, Country
- Example input: “Sam Lee, 12 Market St, Bristol, BS1 4QA, UK”
- Expected result: Address appears as “Sam Lee, 12 Market St, Bristol, BS1 4QA, UK” in the list
Common pitfalls when writing acceptance criteria
- Too vague: “Works correctly” or “User can easily save an address.” Replace with observable behavior.
- Too many UI details: “Button is blue and on the right.” Focus on behavior unless UI specifics are essential.
- Mixing multiple features: “Save address and also set as default and also validate international formats.” That often indicates the story needs splitting.
Common splitting patterns (with practical examples)
Splitting is the skill of turning a large story into smaller stories that can be completed within a Sprint while still delivering value. The goal is not to create “technical tasks,” but to create smaller slices of user value.
Pattern 1: Split by workflow step
Use when the user journey has distinct steps that can stand alone.
Large story:
As a shopper, I want to return an order so that I can get a refund.Split by steps (each delivers value):
As a shopper, I want to see which items are eligible for return so that I know what I can send back.As a shopper, I want to request a return for an eligible item so that the store knows I am sending it back.As a shopper, I want to download a return label so that I can ship the item back.
Pattern 2: Split by data type or variation
Use when the same behavior applies to different categories of data, and you can start with one category that provides value.
Large story:
As a user, I want to upload documents so that I can submit my application.Split by document type:
As a user, I want to upload a PDF document so that I can submit my application.As a user, I want to upload image files (JPG/PNG) so that I can submit my application.As a user, I want to upload multiple documents so that I can submit all required evidence.
Tip: Choose the smallest data type that still supports a real user scenario (often one file type first).
Pattern 3: Split by happy path vs. edge cases
Use when you can deliver a basic, valuable flow first, then add robustness.
Large story:
As a customer, I want to reset my password so that I can regain access to my account.Happy path story:
As a customer, I want to reset my password using an email link so that I can regain access to my account.Edge case stories (still valuable, but can come next):
As a customer, I want the reset link to expire after a set time so that my account stays secure.As a customer, I want to request a new reset email if the link has expired so that I can still regain access.As a customer, I want to be prevented from reusing my last password so that my account stays secure.
Warning: Do not use “happy path first” as an excuse to ignore critical security or compliance needs. If an edge case is actually a must-have, it belongs in the same Sprint slice.
Pattern 4: Split by risk (spikes, unknowns, and high-impact parts)
Use when uncertainty is high. The idea is to reduce risk early by validating assumptions.
Large story:
As a finance user, I want to export transactions to my accounting system so that I can reconcile accounts.Risk-based split:
As a finance user, I want to export a small sample of transactions to a CSV so that I can validate the data format.As a finance user, I want to export transactions for a selected date range so that I can reconcile a specific period.As a finance user, I want exports to include tax fields so that I can reconcile accurately.
Optional learning story (time-boxed investigation):
As a developer, I want to verify the accounting system import constraints so that we can design a compatible export format.Keep investigation work time-boxed and aimed at producing actionable information (constraints, examples, a recommended approach).
How to confirm shared understanding via examples and questions
Even well-written stories can be interpreted differently. Shared understanding is built by discussing examples, asking clarifying questions, and aligning on what “done” means for the story.
Use examples as the primary tool
Instead of debating abstract wording, use specific scenarios:
- Example scenario: “A shopper has two saved addresses, one in the UK and one in France. What should be shown at checkout?”
- Example data: “Postal code includes letters in the UK. Do we accept that?”
- Example outcome: “After saving, does the new address become selected automatically?”
Question checklist for story conversations
- User and value: Who uses this? What problem does it solve? What is the smallest useful outcome?
- Scope boundaries: What is explicitly in scope? What is explicitly out of scope for this story?
- Rules and constraints: What validations apply? Any limits (max length, max count, permissions)?
- Dependencies: Does this rely on another system, data source, or configuration?
- Observability: How will we know it works (UI change, API response, audit log, notification)?
- Test examples: Can we list 3–5 example cases (including at least one negative case)?
Mini-technique: “Read it back” in plain language
Have one person restate the story and acceptance criteria in their own words. If two people restate it differently, you have found ambiguity worth resolving.
Mini-technique: Example mapping (lightweight)
Create three lists during discussion:
- Rules: statements like “Postal code is required.”
- Examples: concrete cases like “BS1 4QA is valid.”
- Questions: open items like “Do we support PO boxes?”
This keeps the conversation structured and prevents hidden assumptions.
Mini-exercises: turn one large story into smaller valuable stories
Exercise 1: Large story to workflow slices
Large story:
As a manager, I want to approve employee timesheets so that payroll can be processed.Task: Split into 3–5 smaller stories that each deliver value and could be completed independently.
One possible split:
As a manager, I want to see a list of submitted timesheets so that I know what needs approval.Acceptance criteria examples: list shows employee name, period, status; only submitted timesheets appear.
As a manager, I want to view a submitted timesheet so that I can verify hours before approving.Acceptance criteria examples: shows daily hours and total; highlights missing entries.
As a manager, I want to approve a timesheet so that it is ready for payroll.Acceptance criteria examples: status changes to approved; approval timestamp is recorded.
As a manager, I want to reject a timesheet with a reason so that the employee knows what to fix.Acceptance criteria examples: rejection requires a reason; employee can see the reason.
Exercise 2: Split by happy path vs. edge cases
Large story:
As a user, I want to schedule an appointment so that I can meet with a specialist.Task: Write one happy-path story and at least two edge-case stories.
One possible answer:
As a user, I want to book an available appointment slot so that I can meet with a specialist.Acceptance criteria examples: user selects a date and time; booking confirmation is shown.
As a user, I want to be prevented from booking a slot that was just taken so that I do not double-book.Acceptance criteria examples: if slot becomes unavailable, user sees a clear message and can pick another slot.
As a user, I want to cancel an appointment so that I can free the slot if my plans change.Acceptance criteria examples: cancellation updates status; slot becomes available again.
Exercise 3: Split by data type and risk
Large story:
As a sales analyst, I want a dashboard of weekly revenue so that I can track performance.Task: Split into smaller stories that reduce risk early and still deliver value.
One possible split:
As a sales analyst, I want to see weekly revenue totals for the last 4 weeks so that I can track recent performance.Acceptance criteria examples: shows 4 weekly totals; data matches a known sample dataset.
As a sales analyst, I want weekly revenue to be filterable by region so that I can compare performance.Acceptance criteria examples: region filter updates totals; default is “All regions.”
As a sales analyst, I want the dashboard to show how revenue is calculated so that I can trust the numbers.Acceptance criteria examples: includes definition (e.g., “paid invoices only”); handles refunds according to agreed rule.
As a developer, I want to validate the revenue data source and refresh timing so that the dashboard is accurate and predictable.Acceptance criteria examples: documented refresh schedule; known limitations listed.
Quick self-check for each split story
- Does it deliver a user-visible outcome (not just internal work)?
- Can it be tested with clear examples?
- Is it small enough to complete within a Sprint?
- Does it avoid bundling unrelated variations?
