Story Storming

---

Origins

Story Storming is a hybrid of two long-standing facilitation traditions. It borrows the rapid divergent-then-convergent energy of Event Storming (Alberto Brandolini's domain-modeling workshop) and applies it to the act of generating, slicing, and refining a backlog rather than mapping a domain.¹ It also draws on Jeff Patton's User Story Mapping, which gave the agile community a precedent for working stories spatially rather than one row at a time.²

The workshop format emerged in the mid-2010s as a response to a chronic problem: refinement-by-meeting was slow, narrow, and dominated by whoever owned the keyboard. Story Storming inverts that — the whole team, sticky notes, walls, a tight time-box — and tends to produce richer, smaller, better-understood stories in less total time.

Why Run a Workshop Format?

A typical refinement session looks like this: the Product Owner walks through stories one at a time, the team asks questions, edits accumulate in the ticketing tool, the next story is opened. The format is linear, the bandwidth is one-conversation-at-a-time, and it tires people out.

Story Storming changes the bandwidth. By giving everyone sticky notes and wall space, the team can work in parallel for stretches — generating story candidates, identifying gaps, proposing splits — and then converge to align on the result. The output is typically:

• A larger surface area of explored ideas than refinement alone produces.
• Smaller stories, because slicing happens with everyone present.
• Stronger shared understanding, because everyone touched the wall.
• A backlog the team owns rather than receives.

The Format

A typical Story Storming session runs 90 minutes to two hours and follows five phases:

1. Frame the goal (10 min)

The Product Owner opens with the outcome the work is trying to produce — the bet, not the feature list. "We want to reduce drop-off in step three of checkout", not "we want to redesign checkout." The framing is what keeps the rest of the workshop focused.

2. Divergent story generation (20 min)

Everyone, silently, writes story candidates on sticky notes. One idea per sticky. No filtering, no debate. The instruction is volume — generate as many candidate slices as possible. This is the move that exposes everyone's mental model of the problem.

3. Affinity grouping (15 min)

The team clusters the stickies into groups — by user, by journey step, by capability, by bet. The grouping reveals the structure of the problem space and the gaps within it. Stickies that don't fit anywhere often turn out to be the most interesting.

4. Slice and refine (40 min)

For each group, the team identifies the walking skeleton — the thinnest slice that delivers something — and the next two or three slices behind it. SPIDR or story slicing patterns are explicitly used here. Stickies that are too big get split. Stickies that are duplicates get merged. Stickies that don't belong get parked.

5. Sequence and converge (15 min)

The PO and the team agree on the ordering of the first slices. Acceptance criteria are sketched for the most-imminent stories. The remaining stickies stay on the wall as a near-term backlog that everyone has seen and can reason about.

What Makes It Work

Three small but non-negotiable practices distinguish good Story Storming from a chaotic brainstorm:

• One idea per sticky. The constraint forces specificity. Long stickies are usually multiple stickies hiding.
• Silent generation before discussion. Talking during divergent thinking shrinks the idea space — the loudest voices drown out the rest.
• The wall is the artifact. Resist the urge to type stickies into Jira mid-session. The spatial layout carries information the tool cannot.

When to Use It

Story Storming is most valuable at three moments:

• At the start of a new initiative, when the backlog does not yet exist and you want to generate one collaboratively.
• When a story turns out to be much larger than expected, and the team needs to slice it together rather than have the PO do it alone.
• When the team has lost shared understanding of where the work is heading — Story Storming re-grounds everyone in the same picture.

It is overkill for routine refinement of small, well-understood stories. Save it for the moments when the bandwidth of a one-conversation-at-a-time refinement is the bottleneck.

Coaching Tips

Start with the outcome, not the features.

If the framing is "redesign checkout," you'll get a redesign-shaped backlog. If it's "reduce step-three drop-off," you'll get a portfolio of bets.

Enforce silent generation.

The instinct is to talk. Resist it. Twenty minutes of quiet sticky-writing surfaces ideas the talkative half would have crowded out.

Keep the wall low-tech.

Stickies on a wall (or a Miro/Mural board) beat a Jira screen. Tools subtly enforce the one-row-at-a-time mode you're trying to escape.

Photograph the wall before disbanding.

The spatial layout is the artifact. A photo preserves the grouping logic that a typed list will lose.

Don't backlog-import everything.

Many stickies will turn out to be premature, redundant, or out of scope. Capture only what you intend to start within the next two iterations.

Don't over-run this format.

Story Storming is a special occasion, not weekly refinement. Used too often, it loses its edge.

Summary

Story Storming is one of those rituals that looks chaotic from the outside and feels efficient from the inside. The combination of silent divergence, spatial grouping, explicit slicing, and tight time-box reliably produces a small-grained, shared-understanding backlog in less total time than traditional refinement would take. It is the format of choice when the question is not "what should we do with this story?" but "what stories should we even have?"

Back to Story Crafting