User Story MappingBUILDING SHARED UNDERSTANDING – GLENN MCCLURE, CSM, CSPO

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

Shared Documentation does not equal Shared Understanding

Stories• Stories are a way to

work—not a way to document

• Stories—tokens for good conversations

• Sometimes Big and Blobby Things

• Think Things Through A Bit before it’s dropped into the PBL

Shallow

Externalize

Refine

Agreement

Shared Understanding

Words & Pics

Walls

More Walls

LET’S BUILD OUR MAP

“User Story Mapping is about having a good old-fashioned conversation and then organizing it in the form of a map” – Jeff Patton

How Will This Help?• Mapping Our Stories Help Find Holes In Our

Thinking• Allows you to see the big picture in your

backlog• Gives you a better tool for making decisions

about grooming and prioritizing PBL• Promotes a collaborative approach to

generating your user stories• It encourages an iterative development

approach where your early deliveries validate your architecture and solution

• Great visual alternative to traditional project plans

• Allows you to visualize dimensional planning and real options for your project/product

Build A Story Map Exercise• Frame the opportunity/

goal / outcome / value• Tell the story of the product

(user steps) from left-to-right (distill tasks into activities)

• Go back and talk about and capture the details of each step

• Use Value driven outcomes to slice out release plans & MVP

Frame Opportunity• What is the big idea?• Who are the customers?• Who are the companies we think

would buy the product?• Who are the users?• Why would they want it?• What problems would it solve for

customers and users they couldn’t solve today?

• What benefits would they get from buying and using it?

• Why are we building it?• If the product is successful, how does

that help us?

STEP 1-Tell the Story (User Tasks)(focus on breadth before depth)

user tasks are the basic building blocks of a story mapCreate a Narrative Flow: Tell the story of the product—What are the high level tasks our users will be doing? Write short verb phrases that say what the specific type of user wants to do. First the user will do this, “and then” this, and then this— flow from left to right.

When your Software is completely done—ships out-Tell me about a day in the life of the people using your product?

STEP 2-Identify User Activities (Backbone)Group Distill Tasks into Activities

STEP 3-Explore & Fill In Details & Options

(User Stories)

Process of Filling the Map Out: • Start Working from the Middle (User Tasks) Out• Keep adding more body to the map• Feel free to rip up cards, replace cards, move cards

around• After a while it will start to stabilize• Move quickly to start to Visualize a UI• Build simple paper prototype which can feed into

our Low Fidelity Mock Ups

STEP 4-Explore Alternative Stories-What About?

• What specific things to users to do here?

• What are alternative things users could do?

• What are really cool things users could do?

• What about when things go wrong?

IDENTIFY HIGH VALUE, PRIORITY AND RISK

SLICE OUT RELEASE PLAN & MVP

Iterate Until Viable-In each release deliver something people can actually use

Concept in Lean Startup Thinking-Eric Ries

Incremental Strategy

Iterative Approach

Build Like An Artist

Development Strategy• Opening Game

• Focus on essential features, user steps that cross through the entire product

• Focus on things that are technically challenging, risky

• Skip optional things users might do, complex business rules

• Build just enough to see the product working end to end

• Midgame• Fill in and round out features• Optional steps users might take• Tougher business rules now• Constantly testing product end to end for scalability,

performance, usability• Endgame

• Refine our release• More efficient, • Improvement opportunities we couldn’t see before