Ein Unverzichtbares Werkzeug für Agile Teams

Einführung

„User Story Mapping“ von Jeff Patton ist ein Muss für jeden, der in der Welt der agilen Entwicklung arbeitet. Das Buch bietet eine detaillierte Anleitung zur Erstellung von User Story Maps, die als Werkzeuge zur Verbesserung der Produktentwicklung und -planung dienen. Es ist nicht nur ein theoretischer Leitfaden, sondern auch ein praktisches Handbuch, das mit zahlreichen Beispielen, Fallstudien und Übungen angereichert ist.

Inhalt und Struktur

Das Buch ist in mehrere Kapitel unterteilt, die sich auf verschiedene Aspekte der User Story Mapping konzentrieren. Es beginnt mit einer Einführung in die Grundlagen und erklärt, warum User Story Mapping wichtig ist. Danach folgen Kapitel, die sich auf die praktische Anwendung, die Erstellung von Maps, die Priorisierung von User Stories und die Integration in den Entwicklungsprozess konzentrieren.

Stärken

• Praktische Anwendbarkeit: Jeff Patton geht über die Theorie hinaus und bietet praktische Tipps und Techniken, die sofort im Arbeitsalltag angewendet werden können.
• Klare Sprache: Das Buch ist in einer klaren, verständlichen Sprache geschrieben, die es leicht macht, die Konzepte zu verstehen und anzuwenden.
• Fallstudien und Beispiele: Die zahlreichen Fallstudien und Beispiele im Buch bieten einen realen Kontext, der das Verständnis der Methodik erleichtert.
• Flexibilität: Das Buch zeigt, wie flexibel User Story Mapping sein kann und wie es an verschiedene Projektgrößen und -typen angepasst werden kann.

Schwächen

• Nicht für Anfänger: Obwohl das Buch sehr informativ ist, könnte es für jemanden, der völlig neu in der agilen Entwicklung ist, etwas überwältigend sein.
• Fokus auf Softwareentwicklung: Das Buch ist hauptsächlich auf Softwareentwicklungsprojekte ausgerichtet, was es für andere Branchen weniger relevant machen könnte.

Fazit

„User Story Mapping“ von Jeff Patton ist ein unverzichtbares Buch für alle, die sich ernsthaft mit agiler Entwicklung beschäftigen. Es bietet nicht nur eine solide theoretische Grundlage, sondern auch praktische Anleitungen, die in realen Projekten angewendet werden können. Trotz kleiner Schwächen ist es ein wertvolles Werkzeug für erfahrene Praktiker und solche, die ihre Kenntnisse vertiefen möchten.

Take Aways

Story mapping is the Rosetta Stone for our digital age.

Live in it, swim in it, laugh in it, love in it /
Removes embarrassing stains from contour sheets, that’s right /
And it entertains visiting relatives, it turns a sandwich into a banquet.—

Tom Waits, “Step Right Up”

Building a map is dead simple. Working together with others, I’ll tell the story of a product, writing each big step the users take in the story on sticky notes in a left-to-right flow. Then, we’ll go back and talk about the details of each step, and write those details down on sticky notes and place them vertically under each step. The result is a simple grid-like structure that tells a story from left to right, and breaks it into details from top to bottom. It’s fun and fast. And those details make a better backlog of stories for our Agile development projects.

Shared Knowledge and understanding

Shared documents aren’t shared understanding!

“It’s not that one person is right or wrong, but that we all see different and important aspects. Through combining and refining our different ideas, we end up with a common understanding that includes all our best ideas.”

“You can’t see or touch “shared understanding,” but you can feel it.”

“The real goal of using stories is shared understanding.”

“There’s always more to build than we have time or resources to build—always.”

Build less

“But if you get the game right, you will realize that your job is not to build more—it’s to build less. 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.

“I sat down with them and reminded them of something they already knew: “I understand that you’re different teams because you’re focusing on different areas, but it’s a major revision of one content management system. You’ll have to release together. You can’t plan a release until you can see it all together. You’ve got to visualize all these dependencies.” They agreed and quickly went to work reorganizing their individual backlogs into a map. Within a few hours they built a map on the wall using sticky notes that told the story of their content management system.”

“The new map, with Risk Stories, gave a better picture for the size and complexity of the road ahead. Project size and complexity were better represented, because they were composed of both the original known stories as well as the new “unknown stories”—the risks, or the knowledge the team needed to gain to confidently move ahead with the known stories.”

“Focus on what you hope will happen outside the system to make decisions about what’s inside the system.”

Finding a Smaller Viable Release

Differentiator: A feature that set them apart from their competition

Spoiler: A feature that is moving in on someone else’s differentiator

Cost reducer: A feature that reduces the organization costs

Table stakes: A feature necessary to compete in the marketplace

Minimum Viable Product

The minimum viable product is the smallest product release that successfully achieves its desired outcomes.

Prototype and test

“Prototype and test with users to learn whether your solution is valuable and usable.”

Build to learn

“His team also built in some simple metrics so they could measure whether people were really using the software, and what they did in the software specifically.”

“Eric and his team actually do get to work building software. But their first goal isn’t to build a minimum viable product. Actually, it’s to build something less than minimal—just enough that potential users could do something useful with it.”

“Treat every release as an experiment and be mindful of what you want to learn.”

Great art is never finished, only abandoned.

Leonardo da Vinci

Tasks

Tasks are 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 form the backbone of the map.

You can slice the map to identify the tasks you’ll need to reach a specific outcome.

“We can both read the same document, but have a different understanding of it.”

Story template

My favourite template: if I’m writing stories on sticky notes or cards, and they won’t be sitting inside a bigger story map, I’ll first give them a short, simple title, and then under it I’ll write:

• Who:
• What:
• Why:

A Checklist of What to Really Talk About

▢ Really talk about who

Please don’t just talk about “the user.” Be specific. Talk about which user you mean. For Gary, he could talk about the band manager or the music fan.
Talk about different types of users. For many pieces of software, especially consumer software, there are very diverse types of users using the same functionality. Talk about the functionality from different users’ perspectives.Talk about the customers. For consumer products, the customer (or chooser) may be the same person as the user. But for enterprise products, we’ll need to talk about the people who make buying decisions, their organization as a whole, and how they benefit.Talk about other stakeholders. Talk about the people sponsoring the software’s purchase. Talk about others who might collaborate with users.There’s rarely just one user who matters.

▢ Really talk about what

“I like my stories to start with user tasks—the things people want to do with my software. But what about services like the kind way beneath the user interface that authorizes your credit card for a purchase, or authenticates you on an insurance website? Your users didn’t make a deliberate choice to get their credit cards pass:[authorized] or have their credentials verified. It’s OK to talk about the services and the different systems that call them. It’s OK to talk about specific UI components and how the screen behaves. Just don’t lose sight of who cares, and why.

▢ Really talk about why

Talk about why the specific user cares. And dig deeply into the “whys,” because there are often a few, and they’re layered. You can keep “poking it with the why stick” for a long time to really get at the underlying reasons why.
Talk about why other users care. Talk about why the user’s company cares. Talk about why business stakeholders care. There are lots of great things hidden inside why.

▢ Talk about what’s going on outside the software

Talk about where people using your product are when they use it. Talk about when they’d use the product, and how often. Talk about who else is there when they do. All those things give clues about what a good solution might be.

▢ Talk about what goes wrong

What happens when things go wrong? What happens when the system is down? How else could users accomplish this? How do they meet their needs today?

▢ Talk about questions and assumptions

If you talk about all those things, you’ve likely stumbled across something you don’t know. Identify your questions and discuss how important they are to get answered before you build software. Decide who’ll do the legwork to get those questions answered, and bring them back to your next conversation. You’ll find it takes lots of conversations to think through some stories.
Take time to question your assumptions. Do you really understand your users? Is this really what they want? Do they really have these problems? Will they really use this solution?Question your technical assumptions. What underlying systems do we rely on? Do they really work the way we think? Are there technical risks we need to consider?All these questions and assumptions may require deliberate work to resolve or learn. Make a plan to do just that.

▢ Talk about better solutions

The really big win comes when those in a story conversation discard some original assumptions about what the solution should be, go back to the problem they’re trying to solve, and then together arrive at a solution that’s more effective and more economical to build.

▢ Talk about how

When sitting in a story conversation, I often hear someone anxiously say, “We should be talking about the what, not the how!” By that they mean we should be talking about what users need to do, not how the code should be written. And I feel the same anxiousness when we talk about the “what” without talking about the “why.” But the truth is, we’re trying to optimize for all three in a good story conversation. What goes wrong is when either party assumes that a particular solution or the way it’s implemented is a “requirement.” Without explicitly talking about how (and if you’re a developer, I know you’re thinking about it), it’s difficult to think about the cost of the solution. Because, if a solution is too expensive, then it may not be a good option.
Be respectful of the expertise of others in the conversation. Don’t tell a highly trained technical person how to do her work. Don’t tell someone intimately familiar with users and their work that he doesn’t understand. Ask questions, and genuinely try to learn from each other.

▢ Talk about how long

Ultimately, we need to make some decisions to go forward with building something or not. And it’s tough to make this sort of buying decision without a price tag.
For software, that usually means how long it’ll take to write the code. In early conversations, that might be expressed as “a really long time” or “a few days.” Even better is comparing it to something already built—“about the same as that feature for commenting we built last month.” As we get closer to building something, and we’ve had more conversations and made more decisions, we’ll be able to be a bit more precise. But we always know we’re talking about estimates here, not commitments.

Stories

The template goes like this

• As a [type of user]I want to [do something]So that I can [get some benefit]

Epics

“An epic is a story that we expect is large, and know needs to be broken down.”

Using Discovery for Validated Learning

“This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful.

We’re Wrong Most of the Time”

Design Thinking

“Talk directly to customers and users. Experience the challenges you’re helping them with firsthand.”

“Really focus on one or a few problems. State 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 solves their problem.”

“the faster you deliver crap, the more crap you get”

Excerpts From User Story Mapping, Jeff Patton