01 / UNDERSTAND
What are user stories?
User stories describe a small piece of product value from the perspective of someone who needs it. They help a team discuss what to deliver, why it matters and how to recognise an acceptable result. The sentence is a reminder for a conversation, not a complete specification.
The familiar role, action and benefit format can help expose missing reasoning. It is optional: a grammatically perfect story can still describe the wrong thing. User Story Map provides a wider view of an activity; individual stories identify increments within that view.
Why use User Stories?
Requests often arrive as screens, components or stakeholder instructions. Reframing a request around the person’s purpose makes it easier to question whether the proposed interface is necessary. A story also gives design, engineering and testing a shared unit of discussion. It should retain enough context that a later delivery decision does not silently replace the original need.
When to use it
USE IT WHEN
The team understands a user situation and needs to break delivery into useful increments.
Design and engineering need to clarify the boundary of a proposed change.
Acceptance discussions are revealing different interpretations of the same request.
When to choose another method
Use User Interviews if the benefit is only an internal guess.
Use User Story Map to understand an activity before splitting it into stories.
Use Service Blueprint when the important change crosses operational responsibilities.
What you’ll need
Bring a specific user situation, the current behaviour and relevant evidence. Involve someone able to explain the need, someone who understands implementation and someone who can challenge testability. Keep policy and accessibility conditions visible. A designer should be able to explain what a person can accomplish after the increment that they could not reliably accomplish before.
What a useful user story contains
Keep the elements that help answer your question and support a decision.
The relevant role, context and trigger, supported by evidence.
What the person wants to accomplish and why it matters.
The useful boundary of this piece of delivery.
The decisions and alternatives that require discussion.
Concrete conditions that distinguish acceptable behaviour from failure.
Dependencies, exceptions and evidence that remain unresolved.
02 / PUT IT INTO PRACTICE
How to write and refine user stories
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Start with an event
Locate a concrete moment in an activity rather than starting with a component name.
A resident needs to move a repair visit because access is no longer possible.
02
State the value
Draft who needs what and the intended benefit. Challenge vague benefits such as a better experience.
A resident wants a replacement appointment without accidentally cancelling the repair.
03
Discuss alternatives
Review the current journey, delivery constraints and possible ways to support the goal.
Could a phone assisted change be a useful first increment?
04
Define the boundary
Separate the smallest useful behaviour from later convenience features.
Initially support one confirmed visit; leave bulk changes outside the story.
05
Write acceptance examples
Describe normal and exceptional situations with observable outcomes.
If the replacement cannot be confirmed, the original visit remains in place.
06
Check the slice
Use Bill Wake’s INVEST checklist to question independence, negotiability, value, estimability, size and testability.
A new database table alone does not let the resident change a visit.
07
Review after delivery
Check whether the increment helped in the intended situation and carry new evidence into later stories.
Observe whether people distinguish a pending request from a confirmed replacement.
Example: changing a repair appointment
Fictional scenario: a housing team receives a request to add a Change button. The proposed story is: a resident with a confirmed visit can request another slot while keeping the current appointment until the replacement is accepted. The purpose is to avoid losing a repair while making new arrangements.
Acceptance examples include an available replacement, a replacement that becomes unavailable and an interrupted request. The team decides that the current appointment must remain visible throughout. A staff assisted confirmation is acceptable in the first increment if the resident can clearly understand its status.
This changes the delivery discussion. The smallest useful story is not the button by itself, and it need not contain a fully automated scheduling system. The team tests the status explanation before committing to automation. The example describes invented requirements, not evidence from a housing study.
03 / BELOW THE SURFACE
Below the surface: small stories can hide a broken promise
A small delivery unit can be locally correct while the surrounding experience remains unreliable.
PROMISE
What can the person rely on at the end?
Distinguish a submitted request from a completed change.
BOUNDARY
Does the slice preserve useful value?
Locate dependencies rather than hiding them in another ticket.
CONFIRMATION
Which example would reveal a false promise?
Include failure and interrupted progress.
A story may pass its acceptance examples because a request can be submitted, while nobody owns the later confirmation. From the delivery team’s perspective the increment is finished. From the resident’s perspective the promise has only begun.
Before splitting a story, name the promise it makes and where that promise becomes true. A useful slice should either complete that promise or make its limited scope understandable. Technical completion and experienced completion can differ. Keep dependencies visible even when implementation is divided across teams.
This is an editorial question for reviewing a slice, not a new scoring framework. Ask a person to explain what they believe has happened at the end. If their answer assumes work the increment does not provide, change the boundary or the status communication.
User Stories companion worksheet
The original two page companion records one story’s situation, purpose, scope, conversation, acceptance examples and questions. The second page reviews the promise, dependencies and evidence after delivery. It is a discussion worksheet, not a substitute for a backlog or an automated test suite.
Practical tips
Discuss the story with the people who will build and test it.
Include an exception that could change the user’s understanding.
Keep the evidence behind the benefit accessible from the story.
Common mistakes
Writing one story for every screen without identifying value.
Using the sentence format as proof that the need is understood.
Splitting away the confirmation or recovery work that makes the increment useful.
What you’ll get
A delivery increment whose purpose and limits are understood. Use its acceptance examples to guide design and testing, then observe whether the delivered behaviour supports the original goal. A passed checklist alone cannot establish user value.