User Stories

Facilitation script

1. 1

   State the goal or feature the session covers. Together, list the user roles involved and what each is trying to achieve.

   8 min
2. 2

   Everyone writes story cards silently, one need per card, in role-feature-benefit form. Post them where all can see and remove duplicates.

   10 min
3. 3

   Take the cards one at a time, most important first. The team questions the product owner until the scope of each story is clear, and rewrites the card if needed.

   15 min
4. 4

   Add acceptance criteria to each discussed story so that it is clear how done will be confirmed.

   10 min
5. 5

   Check stories against INVEST and split the ones that are too big. Park questions nobody in the room can answer, each with a named owner.

   7 min
6. 6

   The product owner arranges the cards in delivery order. Agree which stories are ready for the next iteration and which need more conversation.

   5 min

Tips

• Treat the card as a reminder to have a conversation, not as a specification; if the room goes quiet and people start polishing sentences, bring them back to talking.

• Write stories with the people who will build and test them, because a story handed over finished skips the shared understanding that makes it useful.

• When a story will not split, look for the seams: different user roles, steps in a workflow, data variations, or the simple case before the exceptions.

Common pitfalls

• Treating the written card as the requirement and skipping the conversation, so the team builds what the sentence says and not what the user needs

• The product owner writes all stories alone beforehand, which turns the session into a reading and removes the shared understanding

• Leaving the benefit clause empty or generic, so nobody can judge whether a smaller or different solution would serve the user equally well

• Writing stories for architectural layers or components instead of slices a user can see, which delays anything usable until every layer is finished

• Detailing the whole backlog to the same depth, which wastes effort on stories that will change or never be built

Variations

For a new product, start with a Story Mapping session to lay out the user's journey and then write stories for the first slice. For stories with tricky business rules, follow up with Example Mapping to turn rules into concrete examples before the story enters a sprint. Remote teams write cards on a shared board or straight into the backlog tool while one person shares the screen; keep cameras on for the conversation step. Some teams prefer job stories, which describe the situation and motivation instead of a user role.

Related methods