user story mapping, discover the whole story

Jeff [email protected]: @jeffpatton

Story Mappingdiscover the whole story

Jeff Pa'on & Associates, [email protected]'onassociates.com, twi'[email protected]'on

Stupid stuff I used to believe about Agile stories:

1. Stories are way to document requirements in Agile processes

2. Good stories are small3. Good product backlogs are

prioritized lists of stories4. Each story we build is valuable to

customers and users

2

mailto:[email protected]



Documents don’t work the way you

think they do

3




Imagine a simple phone conversa?on...

Jen Yates’ Cake Wrecks: www.cakewrecks.com4



http://www.cakewrecks.com



Specifying in wri?ng doesn’t work well

h5p://www.cakewrecks.com/

Cake Wrecks, book by Jen Yates, 5







Some<mes mistakes are less funny11

“... engineers failed to make a simple conversion between English units and metric, an

embarrassing laps...”




When we share and sign off a document we may believe we understand

12




Kent has a disruptively simple idea

13




Stop it.Stop exchanging documents.

Tell me your story.

If we we could just talk about this, we could figure it out

together.

14




The original idea of a story was simple: use it to facilitate a conversa?on

15

someone who wants something

I’ve written on the card what

I want

We’ll talk about it to

discover the details of what I need to build.

someone who builds

something




Stories get their name from how we use them, not how we

write them.

16




But, we still managed to screw that up

17



blah blah blahdy-blah b’blah blah blahdy-blah blah

blah blahdy-blah

b’blah blah blahdy-blah blah

blah blahdy-blah

b’blah blah blahdy-blah blah


This is a Scrum backlog grooming session

18




This isn’t the kind of conversation Kent

had in mind

19




Something special is going on during an

effective conversation

20




With a shallow discussion, we may all take away something different

21




When we externalize our thinking with words and pictures, we detect differences

22




When we combine and refine, we arrive at something be'er

23




A4erwards, when we say the same thing, we actually mean it

24




Shared understanding and alignment are the objec;ves of collabora;ve work

✴ Credit for this illustra;on goes to ThoughtWorks’ Luke Barret. Jeff PaGon drew these illustra;ons based on Luke’s. Luke doesn’t recall where he first saw this cartoon.

25




Words and pictures help everyone build shared understanding

26




To build shared understanding, use sketching and recording on walls and whiteboards

27



Jeff Pa'on & Associates, [email protected]'onassociates.com, twi'[email protected]'on 28




Shared Understanding and collabora?on at Atlassian

29





30





31




What you record during conversa?ons works like a vaca?on photo

Looking at it helps you remember details that aren’t in the photo

32



!Jeff Pa'on & Associates, [email protected]'onassociates.com, twi'[email protected]'on

What you record during conversa?ons works like a vaca?on photo

Looking at it helps you remember details that aren’t in the photo

33




Effective story conversations build shared understanding

The best documents use words and pictures to help recall our

conversations, they don’t replace conversations

34




Y

You’ll have to think things through

35




This is a cake for a baby shower







Y

I don’t think they thought this through...

37




This is a cake for a baby shower







Talk about the outcome, not just the output

output outcome

we want thiswe build this

41




Stories are an an?dote to “requirements”

SoYware development has been steered wrong by the word ‘requirement,’ defined in the

dic?onary as “something mandatory or obligatory.”

The word carries a connota?on of absolu?sm and permanence, inhibitors to embracing change. And

the word ‘requirement’ is just plain wrong.

42




Kent suggested we talk about what

happens when things come out

43




Talk about who does what, and why What I was thinking

of was the way users some?mes tell stories about the cool new things the

soYware they use does:

“I type in the zip code and it automatically fills in the city and state without me having to touch a button!” I think that was the example that triggered the idea. If you can tell stories about what the soYware does and generate energy and interest and a vision in

your listener's mind, then why not tell stories before the soYware does it?

44




Say “Hi” to Rachel45




Rachel and her team at Connextra created a clever conversa?on starter

46

whowhatwhy

conversation starter

good short title




Focus discussion and collaboration around

who will use the product and how they’ll work “later,” after delivery

47




Stories have a simple lifecycle

Conversa?on

Confirma?on

* Ron Jeffries coined the 3 C’s in Extreme Programming Installed

!! !

?

Card




If you replace a conversa?on with a document, you’ve stopped using stories

49






Stories aren’t a different way to write requirements, they’re

a different way to work

50




It’s easy to get nowhere fast

51




A Story Map helps organize discussion about user’s experience with our product

Gary Levitt, owner & designer of Mad Mimi

52

Explore Details• smaller steps• alternative steps• UI details• technical details

Map Use (from the user’s perspective)

backbone (gives structure to the map)

Frame the idea(why build the

product)

Understand Users(what are their goals)




Gary ul;mately built a successful product

53


A story map is a simple way to tell a story and break it down into parts

54




Build story maps in small collabora?ve groups

55




Use the map for con?nuous discussion

56




Discussions drive out more details, validate, and build shared understanding

57

Talking through the map with multiple users and subject matter experts helps test it for completeness




Use story maps to understand your whole product or feature’s experience

Use mapping to break down big stories without losing the

big picture

58




If I hear MVP one more time, I’m going

to shoot myself

59




Plan by slicing the map into holis?c valuable releases

60





61





62




Target outcome

Outcome-centric roadmap

MVP MVP: Minimal Viable Product๏ The smallest product

you could build that reaches your target outcomes

It’s NOT -‐ the crappiest thing that could possibly work

If it dies in the market, it’s wasn’t viable

Your job is to build LESS soYware

63




But, how do you know if you’re

hypothesis is correct?

64




You don’t

65




Delivering your hypothe?cal solu?on a piece at a ?me delays learning

66

Hypothesis:

output outcome

$$$impact

* Artwork and concept described by Henrik Kniberg




Deliver minimum viable product tests to a smaller audience to find what’s really viable

67

Hypothesis:

output outcome

$$$impact

MVP?somewhere around here

* Artwork and concept described by Henrik Kniberg




Eric has organized his backlog into a series of release slices

68




Nothing leaves their board un?l there’s been a discussion on what they’ve learned

Snag-‐a-‐Job’s task board photo courtesy of David Bi5enbender

Explicit release step

Explicit measure step & metrics

69




You won’t finish on time

72




“accurate estimate” is an oxymoron

73




To release benefit on a schedule we’ll need to budget, and leverage

incremental and iterative thinking

(What’s the difference?)

74




“incremen?ng” builds a bit at a ?me

1 2 3 4 5

Incrementing calls for a fully formed idea.

And, doing it on time requires dead accurate estimation.

75




“itera;ng” and “incremen;ng” builds a rough version, validates it, then slowly builds up quality

1 2 3

A more iterative allows you to move from vague idea to realization making course corrections as you go.

4 5

76



Jeff Pa'on & Associates, [email protected]'onassociates.com, twi'[email protected]'on193 77

Many organiza?ons consider revising the same func?onality as failure. Itera?on is not tolerated.

timeJeff Pa'on & Associates, [email protected]'onassociates.com, twi'[email protected]'on

Work like an ar?st to envision and build the product holis?cally

78

“Art is never finished, only abandoned.”

-Leonardo DaVinci




End Game

Over time the value of stories begin to diminish signaling it’s time for release

Mid Game

Once we’re confident we have the “shape” of the product right, we begin to pile in value

Opening GameEarly stories emphasize iteration and learning. We need to be sure we’re building the right product

Organize work to maximize learning

The inverse of risk is knowledge

Learning earlier about delivery risks helps us finish on ?me

Alistair Cockburn refers to cuhng the small “polishing” stories as “trimming the tail.”

timeac

qui

red

pro

duc

t kno

wle

dg

e

79




Use a story map to slice out a delivery strategy

80




Consider these four story splihng heuris?cs that build up qualityBare Necessity For the feature to be minimally demonstrable – but not releasable, what is the minimal func<onalityExample: A form with only necessary fields and no valida9on

Capability & Flexibility What would add the ability to perform the user task in different ways? Adding in sub tasks that are op<onally performed?Example: a form with op9onal fields, date lookup tools, input transla9on on dates

Safety What would make this feature safer to use? For both the user, and for the business paying for the soPware?Example: input valida9on, enforcement of business rules such as credit card valida9on

Usability, Performance, Sex AppealWhat would make this feature easier to use? More desirable to use? Faster to use?Example: auto-‐comple9on, sexy visual design, speed keys

81

* Adapted from Gerard Meszaros’ “Storyotypes”




user

task

s to

sup

port

releaseD D D D D I IB- C C- D D D DA- B B- B B B B-A- A B A A- A- B-

sprint

1234

Product goal: (in 4 sprints) ship the best product possible82

Building up quality itera?vely and incrementally ships the best product possible

1. We know each story can be split into at least four parts2. Early itera<ons strive to build bare necessi<es, later itera<ons build up quality

3. Evalua<ng readiness based on subjec<ve quality to understand doneness




Sculpture at various stages of comple<on, Musée d’Orsay, Paris

Product Owners must understand the delivery strategy that leads

to a finished product




Build up software iteratively and

incrementally to release the highest quality possible on time

84




1. Tell stories, don’t just write them2. Use simple visualizations to anchor the stories

you tell

3.Tell the whole story to find the parts that matter most

4. Think things through: minimize output, maximize outcome and impact

5. Build to minimum viable product tests to find what’s minimum and viable in the market

Effective stories connect everyone to the purpose of your product

70



Jeff [email protected]: @jeffpatton

Story Mappingdiscover the whole story