Some sketches about using User Stories to facilitate iterative, incremental development: bad, better, best.

3 min readJul 10, 2022

--

See also User Stories to facilitate shared understanding.

To provide context, “Think Big Work Small”.

“Successful product teams figure out how to think big and work small.”
John Cutler, “TBM 46/53: Think Big, Work Small”

See also TBM 4/52: Think Big, Work Small (Part 2) — by John Cutler (substack.com) which has a nice diagram overview.

Bad (😞): Just big stories with no breakdown

Three stories: “Solve global poverty”, “Solve global hunger”, “Solve gender inequality”. Developer responding with “Uh, I think these stories might be too big” — Just big stories are difficult to deal with and deliver

Bad (😞): Just small stories with no larger context

Two stories: “Make titles consistent”, “Add Y to Z”. One developer asks: “Why are we doing any of this?” Another developer responds: “No idea.” — Just small stories provide no larger context

Better (🤔): Using bigger stories to provide context for smaller stories

“Make interfaces consistent across products” as a parent story of two children stories “Make titles consistent”, “Add Y to Z” — Bigger stories providing context for smaller stories

Best (😄): Product strategy logically connected to stories

Cause effect diagram linking “X billion by 202x” to the two stories “Make titles consistent”, “Add Y to Z” — Strategy logically connected to stories

To encourage iteration, play Good-Better-Best.

From User Story Mapping by Jeff Patton:

What’s GOOD ENOUGH to get things working?
What would make it BETTER?
What’s the BEST version we can imagine?

Bad (😞): Best version only

3 stories that are all the best version. Developer responds with: “Uh, it might take a while before we can release any of this.” — Only having the best versions for stories means it will take a while to release anything

Bad (😞): Each story is good enough; overall product isn’t

Product Manager responding to 3 stories that are “good enough”: “Technically each story is good enough but the overall product isn’t releaseable.” — Each story can be good enough, but the overall product might not be

Better (🤔): Good enough, better, best

2 sets of stories with good enough, better, best versions. Developer asks: “Which version do you want?” — Good enough, better, best provides options

Best (😄): Targeted good enough, better, best

Good enough versions only for commodity capabilities; good, better, best versions for differentiating capabilities. Developer asks: “Which version do you want?” — Target good enough, better, best for differentiating capabilities

To avoid unnecessary effort, provide detail just-in-time.

Bad (😞): Stories covering all the breadth and depth up-front

Full breadth and depth story map. “It took us a few months but we’ve mapped out everything. Time to shift to Build It.” — All the breadth and depth up front

Better (😞): Stories covering overall breadth first

Breadth-first story map. “Okay, we get the overall scope but there are still some areas we’re not sure about that will affect what we’ll do first…” — Breadth-first

Best (🤔): Stories covering overall breadth first plus targeted depth as useful

Story map with breadth and some depth. Additional detail for: 1. What’s coming up next; 2. Anything we want to inform an upcoming decision — Overall breadth-first plus targeted depth as useful

Iterative Development

Incremental Development

Extreme Programming

Some rights reserved

Jason Yip

Written by Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl

Help
Status
About
Careers
Press
Blog
Privacy
Terms
Text to speech
Teams