User stories are refined together, in sessions with the owner, the people who will use the result and the webmasters on the job. Run well, a session ends in sharper stories rather than a longer job.
On the Sean Dinwiddie’s Webmastery team, planning is hybrid: each job starts from a written scope that names its user stories, and sessions like these are used where they help.
Where stories get refined
User story workshops
Before the written scope is signed, a workshop refines the stories in one sitting. During it:
- The owner and the webmasters read each story aloud and ask what it leaves out.
- A question no one in the room can answer is written down with the name of the person who can.
- The workshop ends when the owner agrees that each story says what they meant.
Sprint planning
On a job run in sprints, Scrum’s planning meeting is where the stories for the next sprint are read again before work starts. During it:
- Any question a team member brings is cleared up.
- The room says who each story serves and how its criteria will be checked, so no one starts on a guess.
Scrum calls the steady work of splitting and sharpening stories before planning Product Backlog refinement, so most stories reach the planning meeting already clear.
Daily stand-ups
When several webmasters share a job, a brief daily check-in keeps their work in step, and a question about a story is raised there rather than guessed at.
Sprint reviews
A review at the end of a sprint, or of any short round of work, shows the owner the finished stories running, and what the owner says refines the stories still to come.
Retrospectives
At the end of a sprint, or of a whole job, the people on it look back at what went well and what to change. The useful findings are about the stories themselves, such as one that had to be rewritten halfway or a criterion no test could check, and they make the next stories sharper. On the Sean Dinwiddie’s Webmastery team, a finding like that doesn’t stop with one job or one webmaster: it goes into the lessons, revised as the practice improves.
What a session settles
Every perspective in the room
The owner, the webmasters on the job and the people who will use the result each see in a story what the others miss, so the room needs all three.
Acceptance criteria
Read each acceptance criterion aloud and ask how a test could fail it. A criterion nothing can fail, such as “the menu is easy to read”, is rewritten until something can, such as “the menu reads on a phone without scrolling sideways”. Then agree what “done” means for each story.
Ambiguities
A word two people read two ways is settled in the session: does “order” include a phone order, and does “today” end at closing or at midnight? The answer goes into the story in the owner’s words, and the scenarios use the same word for the same thing.
Effort
Webmasters say what each story touches and how large it is, so the written scope can price the job, as a share of the published fee, before it starts.
Priority
The owner orders the stories by what the business needs first, and the webmasters say which ones depend on others, so everyone in the room knows why the order is what it is.
Epics
An epic is a story too large to build and check in one piece, such as “customers can order ahead”. A session splits it into stories that each deliver something the owner can see working, such as choosing a pickup time, and each becomes its own line in the written scope.
User feedback
Where you can, bring in feedback from the people who have tried the software, such as the counter staff on a trial run. Their feedback shows what a story missed.
Room for change
A story can change in the session: its wording, its criteria, how it is split. Welcome those changes, since a story is cheapest to change while it is still words.
The outcomes, in writing
The session’s refinements go into the stories themselves the same day, and the owner gets the revised stories in writing. An addition goes out on its own, as a quote, so the owner can tell a refinement from a change to the job.
To try it, read one of your own stories aloud to the person who asked for it, and sort each change they ask for into a refinement or an addition: the first goes into the story that day, the second becomes a story of its own.
Collaborative sessions turn a draft story into one the whole job can be checked against: its criteria agreed, its terms plain and its place in the scope settled.
That completes Module 1: a need found, written as a story and agreed in the room, with criteria a test can fail. Module 2, on behavior-driven development (BDD), turns each criterion into Given, When, Then scenarios that run as tests.