Book notes: User Story Mapping

Posted on In

This is an awesome book by Jeff Patton published in 2014. It feels to me like a mandatory step in the product engineer path. Its has been an interesting process to digest this book and to put this technique and new thoughts in practice.

This technique is a recommended starting point technique in Domain-Driven Design Starter Modelling Process that can be useful at the understand and discover step.

But just one little spoiler: This book is not only about the SM technique in fact that is the less important part. It’s more about “rediscovering” the whole designing process and the building blocks, and things that you probably do today in your team by inertia. Cool stuff, I promise.

Here are my notes:

“Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.”

First

“The goal of using stories isn’t to write better stories.”
“The goal of product development isn’t to make products”.”
“Shared documents aren’t shared understanding.”
“The real goal of using stories is shared understanding.“
“To help remember, photograph, and shoot short videos of the result of your conversations.”
“The Truth is, your job is to change the world.”
“Your company can’t get what it wants unless your customers and users get something they want.”
“There is always more to build than we have time or resources to build - always.”
“Minimize output, and maximize outcome and impact.”
“Stories aren’t a written form of requirements, telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.”
“Stories aren’t the requirements. they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.”
“Your job isn’t to build more software faster, it’s to maximize the outcome and impact you get from what you choose to build.”

1 Big Picture

“Stories get their name from how they should be used, not what should be written.”
“STMP are for breaking down big stories as you tell them.”
“Talk and doc. write your cards or sticky notes to externalize your thinking as you tell stories.” => Avoid Vaporization and externalize thinking.
Frame your Idea => Find your Customers and Users =>
“Reorganizing cards together allows you to communicate without saying a word.”
“Mapping your story helps you find holes in your thinking.”
“Kilometer wide, centimeter deep.” => Focus on the breath of the story before diving into the depth.

2 Plan to build less

“There’s always more software to build than you have people, time or money for. Always.”
“Map for a product release across multiple teams to visualize dependencies.” Mapping groups => build shared understanding.
“Scope does not creep, understanding grows.” => Understanding holes appear, and it’s ok.
“Focus on what you hope will happen outside the system to make decisions about what’s inside the system.”
“Focus on outcomes - what users need to do and see when the system come out - and slice out releases that will get you those outcomes.”
“Focusing on specific target outcomes is the secret to prioritizing development work.” => Prioritize outcomes not features.
Finding smallest release tips, You can split stories based on:

  • Differentiator
  • Spoiler
  • Cost Reducer
  • Table stakes

MVP

“Minimum viable product is not the crappiest product you could possibly release.”
“The minimum viable product is the smallest product that successfully archives its desired outcomes.”

  • What are our Biggest risk assumptions?
  • What can I do to learn something to replace risk or assumptions with real information?

“A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption”.

3 Plan to Learn Faster

“First story discussion is for framing the opportunity” => Idea? Customers? Users? Why? Who? What Problem Solves? (Why?), Why build it?
“Validate that the problems you’re solving really exist.” => Envision Solution => Prototype => Test With Users.

  • Avoid “I like It”.
  • Find real day by day usage DATA.

Only Highest priority should be moved to the development Board.=> Story mapping backlog != development task boards.
Build Less than MVP to start. Iterate with feedback and real usage data unitil viable. Only then, will it be “safe to market”. => Iterate Until Viable

Incremental delivery of useful and testable experiments
“Treat every release as an experiment and be mindful of what you want to learn” => Build to Learn
Validate Learning concept => From Lean Startup

Validate Learning Loop:

  1. Build => MVP => Experiment
  2. Measure => With customers and users => Subjective and Objective Data
  3. Learn => Better Ideas

4 Plan to Finish on Time

“Map only what is needed to support the conversation.” => Feature Scope.
“The best estimates come from developers who really understand what they’re estimating.”
Split in slices, not in releases or sprints, split by learning goals.
“The more you measure, the better you are at predicting”
Manage your budget.
Expose risk in your map.
“Iterative thinking to evaluate and make changes to what you`ve already made.”
“Use Incremental thinking to make additions.”
EJ: Game Strategy =>

  • Opening game: Essentials => End to end working product, focus on risky or challenging things.
  • MidGame: Features around. => Optional steps, scalability, Tests, performance…
  • EndGame: Refine. More sexy. => Improve opportunities with real data.

5 Story Mapping

In this chapter there is a col recommended exercise of building a story map.

  1. Write User Tasks
    “User tasks are the basic building blocks of a story map.”
    “Use the goal-level concept to help you aggregate small tasks or decompose large tasks.”

  2. Organize your story
    “Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.”

  3. Explore alternative stories
    “Details, alternatives, variations, and exceptions to fill in the body of the map.”

  4. Distill Your map to make a backbone
    “Activities aggregate tasks directed at a common goal.”
    “Activities and high-level tasks form the backbone of the story map.”

  5. Slice out tasks that help you reach a specific outcome
    “Use slices to identify all the tasks and details relevant to a specific outcome.”

Tasks:

  • Short verb phrases that describe what people do.
  • Tasks have different goal levels.
  • Tasks in a map are arranged in a left-to-right narrative flow.
  • The depth of a map contains variations and alternative tasks.
  • Tasks are organized by activities across the top of the map.
  • Activities from the backbone of the map.
  • You can slice the map to identify the tasks you`ll need to reach a specific outcome.

It’s a now-map, not a later map. => Understand how people work today:
Release strategy != learning strategy != development strategy.

Note: This is another col guide for that.

6 Stories

Concept originated by Kent Beck:

“We can both read the same document but have different understanding of it” => Problem in the old times.
“The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.”
“Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.”
“If you’re not getting together to have rich discussions about your stories, then you’re not really using stories.”

  • Card => Write lots of cards or build a story map.
  • Conversation => Support conversation with words and pictures.
    “Story conversations are about working together to arrive at the best solution to a problem we both understand.”
  • Confirmation => when its time to build, use acceptance criteria to record your agreements.

7 Telling Stories

Use the simple story template to start conversations:

“As a [type of user]”
“I Want to [do something]”
“So that I can [get some benefit]”

Avoid template-zombie stories.
It doesn’t need to be written in a template to be considered a story.
Things to talk about:

  • Who?
  • What?
  • Why?
  • What’s going on outside the software?
  • What goes wrong?
  • Questions and assumptions.
  • Better solutions.
  • How?
  • How long?

Create Vacation photos => Photos that help all to remember the conversation.

8 Not all is in the card

Product Owner, Business Analyst, UX Designer, Developer, Tester, Product Manager => Different people => Different conversations. => Each one with Its point of view, worries and contributions.
“Use a document camera or web camera during a video conference to let remote people see what’s being created on the wall.”
“When collaborating remotely, use tools that allow everyone to see, add to, and organize the model concurrency.”
What should be written inside a story? => Short Title, description, number, estimate size or budget, value, metrics, dependencies, status, dates.
“Use tools to post pictures, videos and text to help you retrain and remember your conversations.”
“Use tools to sequence, track and analyze progress.”

9 The Card is the beginning

Card => Conversation => Confirmation => => Construction => Consequences
“Handing off all the details about the story to someone else to build doesn’t work, do not do that.”
Build oral tradition to storytelling.

  • Good: Story driven communication => Shared Understanding => Spread with discussion => Build software with shared understanding.
  • Bad: Document driven communication => Shared Understanding => Read documents will end with other understanding => Software does not match expectations.

Measure results:

  • UX Quality
  • Functionality Quality
  • Code Quality

Alistair Cockburn => “For every story you write, you need to write three in your backlog.” => Build to learn => Write 1 story. And then write other 2 stories that say “Fix previous story”. On Agile Process => Learning is the purpose.

Not always Software.

  • Agile manifesto 2001 => Working software over comprehensive documentation
  • Kent Beck 2011 => Validated learning over working software ( or comprehensive documentation)

“Try using stories to drive the making of anything, whether it’s software or not.”

10 Select stories

Solution expensive => Consider other to reach the goal
Solution affordable but big => Split into small plans.
Cake => Cupcake. => Do not deliver half baked cake, deliver half cake.

11 Breaking stories

“A right-sized story from the user’s perspective is one that fulfills a need.”
“A right-sized story from a development team’s perspective is one that takes just a few days to build and test.”
“A right-sized story from a business team’s perspective is one that helps a business achieve a business outcome.”
“Conversations are one of the best tools for breaking down big stories.”
“Stories are like rocks, if you split them, they’re all stories no matter size.”
“An epic story that we expect is large, and now needs to be broken down.”

Storytelling:

  1. Evaluate Opportunities
    “Use opportunity discussion to agree the problem is worth solving - to make a go forward or trash decision.”

  2. Discover a Minimum viable solution
    “Use discovery conversations and exploration to find small, viable solutions.”

    • Who are the customers and users?
    • How do they meet their needs today without your solution?
    • How would the world change for them with your solution?
    • How might your solution look and behave?
    • How long might your solution take to build?

  3. Deep drive in Story workshops => Refinement in SCRUM
    “Use deep-drive story workshops to discuss the details, break down stories, and really agree on specifically what we’ll build.”
    (Stories in) => Who? what? why? how? => (Right-sized stories output)
    Output minimizer => Discard stories

  4. Daily collaboration
    “Use conversations as you build to fill in details and give feedback on what’s being built.”

  5. Evaluate pieces as a team
    “Frequently reflect on product quality, your plans, and the way you work.”

    • Product quality: UX? Function? Technical? => Stories to improve or change the product.
    • Plan: Done? Velocity? => Stories with work remaining.
    • Process: Working? not working? change?

  6. Evaluate with customers, and users
    “Learn by testing meaningful chunks of working software with customers and users.”
    Users and customers use software to reach a goal, the team observes, learns and writes stories to improve the solution.

  7. Evaluate with business, stakeholders
    “Keep your progress and quality visible to stakeholders inside your organization.”

    • What have we built so far?
    • What we’ve learned?
    • What do we believe is enough to release?

  8. Release and keep learning
    Evaluate after release => Data + Observation + Insight + Opportunities

12 Creating right-sized stories

“Requiring a single product owner to write all of the stories and be present for all story conversations doesn’t work.” => All the team breaks stories, not only the PO.

The solution we want: Valuable + Usable + Feasible

“A small cross-functional team led by a product owner orchestrates product discovery work.”
“Support product owners with a core team that includes user experience, design expertise, adn technical expertise.”

Product discovery Team => UX designer + Senior Engineer + Product Owner (Strong collaborative leader)
The Discovery team needs lots of others to succeed => Delivery team + Experts + Business stakeholders + Customers & users.

Crowds do not collaborate => a good option is a workshop with the three amigos: Developer + Tester + Product Discovery team member.

Client-Vendor Anti-pattern:

  • Client: Requirements
  • Vendor: Estimate commitment
  • Client: Order
  • Vendor: Delivery
  • Client: Acceptance

Generates: Bad estimations, not early validation, more waits, waste risk generation, not shared understanding, problem-solution conversation is replaced by agreements-requirements => No one wins.
The Relationship should be more like a patient-doctor than a Waiter-diner’s.

“When acting as product owner for other stakeholders’ ideas, take on the role of a producer who helps them succeed.” => PO is a producer => “like a doctor”

13 Opportunities

User story mapping not recommended here, better : Opportunity Canvas or User’s Journey

14 Discovery

“If the only thing you create while making sense of a big, ambiguous opportunity is smaller stories, then you’re probably doing it wrong.”

Steps for discovery:

  1. Frame Idea
    • What problem
    • What metrics affected
    • List customers and users
    • List risk and assumptions
  2. Understand customers and users
    • “Sketch simple personas”
    • “Build lightwith personas together to build shared understanding and empathy within the teams.”
    • “Create organizational profiles or orgzonas”
    • “Map how users work today”
  3. Envision your solution
    • “Map your solution” => Story map.
    • “Use cases”
    • “Words and pictures”
    • “Visualize your user interface to build shared understanding of the solution” => prototypes
    • “Validate completeness”
    • “Validate engineering concerns”
    • “Play “what about””
  4. Minimize and Plan
    • “Story map used for slicing”
    • “If you’re not cutting away more ideas than you keep, you’re probably not doing discovery work right.”
    • “Viable means successful for a specific business strategy, target customers, and users.”
    • “Prioritize: 1.specific business goals, 2.customers, and users, and then their goals, before prioritizing 3.features.”

Discovery is for building shared understanding.

15 Validate learning

Bad old days:
Smart person => Big Idea => Big Solution (Lot of time) => Ship It => Customers react

Design Thinking:

Empathize => Define => Ideate => Prototype => Test

“Talk directly to customers and users. Experience the challenges you’re helping them with firsthand.”
“Really focus on one or a few problems. Statue them specifically.”
“Deliberately come up with multiple possible solutions to customer and user problems.”
“Build simple prototypes to explore your best solutions. Advance prototypes to a level of fidelity that allows users and customers to evaluate whether the solution really solver their problem.”
“Get your solutions in front of the people who will buy or use your product. Don’t expect them to be a success at first. Iterate and improve them.”

Design thinking => can go wrong for several reasons

  • Start without clear target audience
  • Too much time researching
  • Too many problems to solve
  • No focus “lest solve all problems”
  • Only let “the professionals” design
  • All data and no empathy
  • Waste time on perfect prototype
  • This is so well researched there’s no need to test with users!
  • It doesn’t matter what it cost to build. It’s the right solution
  • Who can we blame for this disaster?

Short validated learning loops => Learn Startup
Lean Startup + Design Thinking:
Passion & Inspiration => Big Idea (define)=> Assumptions => Risk Assumptions => Right sized prototype => Focused tests => Small Learning => Again Assumptions. Loop: Learn => Build => Measure

“In a Lean Startup approach, failing to learn is frequently the biggest failure.”

16 Refine, Define and Build

Conversations to be effective => Include the right people.

A good way to split stories: Good-Better-best, split into smallest stories using:

  • Good enough
  • Better
  • The best

Story map for delivery can be used in a mapped backlog. (To show delivery progress.)

17 Stories like asteroids.

Cluster, Delete and split only when needed.

There are very small fixes that are so small that probably do not need to be written as stories, just fix it.

18 Learn from everything you build

“Software is never really done.”
“Outcomes are never insured.”
“Improvements made after release are the most valuable.”

Forewords

Martin Fowler

Story mapping is a technique that provides the big picture that a pile of stories so often misses.

See stories like “one way communication”, from analyst to developers, is a mistake. Stories are supposed to spark conversations”. Programmers who understand story mapping can better see the broader user context and can participate in framing the software. Kent Beck called out communication as a key value of effective teams. Stories are the building blocks of communication between developers and those who use their work.

Alan Cooper

It’s really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms. Patton’s story mapping approach is the bridge over this chasm.

Agile development is not a useful design tool by itself, its just a design-friendly approach. Interaction design it’s a better approach to create product that customers love.

Marty Cagan

How strong product teams operates:

  • Good teams have compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.

  • Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers’ struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.

  • Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.

  • Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meeting to generate prioritized roadmaps.

  • Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something.

  • Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective functional areas, and tasks that others make request for their services in the form of documents and scheduling meetings.

  • Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are still waiting for permission to run a test.

  • Good teams insist they have the skill sets necessary to create winning products, such as strong interaction design. Bad teams don’t even know what interaction designers are.

  • Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better, Bad teams show the prototypes to the engineers during sprint planning so they can estimate.

  • Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s response to their latest ideas, Bad teams think they are the customer.

  • Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several interactions to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality.

  • Good teams understand the need for speed and how rapid interaction is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.

  • Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad teams complain about being a sales-driven company.

  • Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.”

  • Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once.

  • Good teams obsess over their reference customers. Bad teams obsess over competitors.

  • Good teams celebrate when they archive a significant impact to the business KPIs. Bad teams celebrate when they finally release something.