Example Mapping – mein Geheimtipp für produktiveres Product-Backlog-Refinement

“Oh je, bitte nicht wieder eine Product-Backlog-Refinement-Session über Akzeptanzkriterien!”

Alle wissen, dass man nicht darum herum kommt, aber viele Teams tun sich sehr schwer damit. Die Diskussionen dauern oft ewig, sind unstrukturiert und sterbenslangweilig. Und doch sind sie notwendig, um Missverständnisse vor der Umsetzung aufzudecken und für die nötige Klarheit zu sorgen.

In diesem Artikel möchte ich dir Example Mapping vorstellen, eine ganz einfache Technik, mit der sich diese Gespräche erheblich abkürzen und wesentlich produktiver gestalten lassen. Sie wurde meines Wissens ursprünglich 2015 von Matt Wynn erfunden. Leider ist sie außerhalb der BDD-Community nur wenig bekannt und daher so etwas wie ein Geheimtipp geblieben.

Warum überhaupt Gespräche über Akzeptanzkriterien?

User Stories sind eine großartige Möglichkeit, zu kommunizieren, welche Funktionalität man realisieren möchte. Das besondere dabei: User Stories werden erzählt. Und dabei können die Zuhörer Rückfragen stellen, Unklarheiten aufdecken und ein echtes gemeinsames Verständnis entwickeln. Diese direkte, bidirektionale Kommunikation ist ein entscheidender Vorteil gegenüber Anforderungsdokumenten. Denn bei unidirektionaler Kommunikation bleiben oft wesentliche Aspekte unverstanden, wertvolle Ideen kommen gar nicht auf oder können nicht integriert werden.

Vielleicht kennst du bereits die von Ron Jeffries geprägten 3Cs funktionierender User Stories: Card, Conversation, Confirmation.

Zunächst ist eine User Story ein leichtgewichtiges Planungsinstrument (Card). Sie ist mit einem Blick zu erfassen und kann gegenüber anderen Stories passend priorisiert werden. Sie enthält aber noch nicht alle Details, die man benötigt, um sie in der richtigen Weise umzusetzen.

Das – unbedingt nötige – Verständnis über diese Details schaffen die Entwickler:innen in einem Gespräch (Conversation) mit dem Product Owner. Die Teilnehmer tauschen sich aus, bis klar ist, woran man erkennt, dass diese Story erfolgreich umgesetzt ist: Anhand von Akzeptanzkriterien (Confirmation). Nutzt man User Stories in einem Scrum-Kontext, finden diese Gespräche als Teil des Product-Backlog-Refinements statt.

In diesem Artikel schauen wir uns an, wie man mittels Example Mapping fokussierte und produktive Gespräche über User Stories führen kann, die zu guten Akzeptanzkriterien führen.

Wie funktioniert Example Mapping?

Bei Example Mapping nutzt ihr farbige Karten, um die relevanten Details zu einer User Story festzuhalten. Die verwendeten Farben schaffen nicht nur eine Übersicht über die Details, sondern ermöglichen es euch auch, schon nach kurzer Zeit Muster zu erkennen und passend zu reagieren. Aber dazu später mehr.

Wie der Name schon sagt, dreht sich Example Mapping um Beispiele. Beispiele sind wahnsinnig hilfreich, um die Sachlichkeit besser zu verstehen und sie bilden eine ideale Basis für Akzeptanztests, die man später im Rahmen der Entwicklung erstellt. Beispiele sind aber nicht die einzige Art von Information, die Example Mapping aufdeckt.

Das Farbschema

Beginnen wir mit dem Farbschema, das ihr für Example Mapping nutzt. Ich empfehle euch, mit der folgenden Kombination zu beginnen. Sie ist allgemein üblich. Prinzipiell könnt ihr natürlich davon abweichen, aber ihr solltet über eure Example Mapping Sessions hinweg immer dasselbe Farbschema verwenden.

• GELB sind Karten, die User Stories enthalten. Jede Mapping Session hat eine gelbe Karte als Überschrift. Sie liefert den Fokus für das Gespräch.
• BLAU sind Karten mit Regeln. Sie stellen später die Akzeptanzkriterien für die Stories dar.
• GRÜN sind Karten mit konkreten Beispielen.
• ROT sind Karten mit noch offenen Fragen.

Der Ablauf

Ihr beginnt, indem ihr die User Story, um die es jetzt gehen soll, auf eine gelbe Karte schreibt und oben platziert. Beschränkt euch dabei auf den Titel, der meist nicht mehr als 2-4 Wörter hat. Gut funktionieren oft Objekt-Verb Kombinationen, die beschreiben, was ein User tun kann.

Startet einen Timer, der euer Gespräch auf 25 min beschränkt.

Eurer Product Owner (oder eine andere kompetente Produkt-Person), darf nun die User Story kurz erzählen und dabei erwähnen, welche Art von User was tun möchte um welches Ziel zu erreichen.

Haltet die bereits bekannten Akzeptanzkriterien als Regeln fest, jede auf einer eigenen blauen Karte, und platziert sie in einer Zeile unter der gelben Karte.

Für jede Regel haltet ihr nun auf jeweils einer grünen Karte mindestens ein, möglicherweise mehrere konkrete Beispiele fest, die die Regel illustrieren. Wichtig: dabei handelt es sich nicht um Teilregeln, sondern ganz konkrete Beispiele. Falls bei euch Verwirrung entsteht, was ein Beispiel und was eine Regel ist, hilft euch vielleicht diese kleine (und dazu lustige) Übung: https://speakerdeck.com/mattwynne/rules-vs-examples-bddx-london-2014.

Fehlen Regeln oder sind sie unpassend formuliert? Ergänzt die blauen Karten entsprechend und findet wieder passende Beispiele.

Bei Gesprächen über die Beispiele und Regeln tauchen typischerweise Fragen auf. Idealerweise werden sie einfach sofort geklärt. Manchmal weiß aber niemand der Anwesenden eine Antwort. Solche Fragen notiert ihr auf roten Karten. Wenn ihr merkt, dass euer Gespräch sich im Kreis dreht, liegt das meist an einer ungeklärten offenen Frage. Anstatt zu spekulieren, haltet einfach die offene Frage fest und macht weiter. Alleine dieser Kniff wird eure Gespräche erheblich beschleunigen!

Oft tauchen auch weitere, bisher unentdeckte Stories auf. Haltet sie auf weiteren gelben Karten fest und platziert sie unten rechts unter den roten. Euer Tisch sieht jetzt möglicherweise so aus:

Wenn das Ende der Timebox nach 25 min erreicht ist, solltet ihr es typischerweise geschafft haben, eine ausreichend gut verstandene User Story passender Größe fertig gemappt zu haben. Wenn nicht, liegt es möglicherweise daran, dass …

• Die Story zu groß ist.
• Ihr noch zu viele Unbekannte habt
• Ihr noch nicht so vertraut mit Example Mapping seid

Entscheidet, ob die Story nun detailliert genug und ausreichend verstanden ist, dass ihr mit ihr in die Umsetzung gehen könnt. In Scrum nennen wir das „ready“.

Hinweis: Eine Story kann durchaus ready sein, wenn es noch offene Fragen gibt, solange ihr zuversichtlich seid, dass ihr diese Fragen nebenbei im Laufe der Realisierung klären könnt. Wenn nicht, könnt ihr entweder die Story kleiner splitten oder ihr klärt zunächst die wichtigen offenen Fragen.

Was ist mit „Beispiel“ gemeint?

Nehmen wir an, ihr habt eine Regel zu der Story „Kauf rückgängig machen“ habt, die lautet: „Rückgabe innerhalb eines Monats möglich“. Dann könnte es folgende Beispiele geben:

• Produkt gekauft am 12. März um 13:15. Rückgabe am 12. April um 18:40. => Rückgabe möglich
• Produkt gekauft am 12. März um 13:15. Rückgabe am 13. April um 0:01 . => Rückgabe nicht möglich
• Produkt gekauft am 1. Februar um 13:15. Rückgabe am 2. März um 0:01 . => Rückgabe nicht möglich

Und beim Gespräch, ob im letzten Beispiel eine Rückgabe möglich sein sollte (schließlich sind es hier ja ebenso 30 Tage wie beim Kauf im März), beschließt ihr, die Regel anzupassen auf „Rückgabe innerhalb von 30 Tagen möglich“.

Pro-Tipp: Wenn das gut funktioniert, probiert mal, ob ihr Zeit sparen könnt, indem ihr ein Beispiel nur schnell mit einem Stichpunkt beschreibt, anstatt jetzt schon passende Beispielwerte zusammenzustellen, z.B. „Rückgabe einen Tag nach Ablauf der Frist“ oder „Rückgabe ohne Kassenzettel“. Doch wenn ihr den Eindruck habt, hinter der Schwammigkeit könnte sich echte Unsicherheit verbergen, dann werdet lieber konkreter.

Das Farbschema spricht zu euch!

Dank der Farben der Karten kann man einige typische Situationen auf den ersten Blick erkennen und leicht entsprechend reagieren.

Der rote Riese

Hervorstechendstes Merkmal hier ist die Vielzahl roter Karten. Sie signalisieren: Hier gibt es noch zu viele Unklarheiten. Vermutlich ist es jetzt noch keine gute Idee, mit der Umsetzung zu beginnen. Die Zeit ist besser investiert, die offenen Fragen zu klären. Fühlt euch nicht schlecht. Ihr habt gerade einen wichtigen Fortschritt gemacht, indem ihr aus lauter nicht bekannten Unbekannten bekannte Unbekannte gemacht habt. Das ist großartig! Schließlich geht’s darum, all das Unbekannte zu entdecken. Fühlt euch als Entdecker und habt Spaß dabei.

Blaue Überbreite

Auf den ersten Blick erkennt man hier: diese Story ist zu komplex. Sie hat eine solche Vielzahl von Regeln, dass sie nicht nur aufwendig zu implementieren, sondern vermutlich auch zu groß für einen Sprint ist. Auch eine sinnvolle Demo beim Review ist schwierig.

Und vermutlich wird sie auch für den Nutzer aufgrund ihrer Komplexität schwer zu benutzen sein. Gibt es vielleicht einen einfacheren Weg? Sucht danach!

Oder versucht ihr gerade, zu viel Funktionalität in eine Story zu pressen? Manchmal denken Product Owner, die gelben Karten seien teuer. Das ist ein Trugschluss. Die Kosten stecken hauptsächlich in der Realisierung der Regeln, also den blauen Karten. Die Entwicklung wird nicht länger dauern, wenn ihr die Story mit den 10 blauen Karten in zwei mit je 5 blauen aufteilt, im Gegenteil.

Grüner Wolkenkratzer

Manchmal sammeln sich viele grüne Beispiele unter einer Regel. Liegen hier vielleicht redundante Beispiel vor? Jedes Beispiel sollte einen relevanten Aspekt der Regel verdeutlichen. Wenn das der Fall ist, ist die Regel vielleicht zu komplex.

Verbergen sich dahinter vielleicht mehrere Regeln, die man besser auseinander ziehen sollte?

Flecken ohne Grün

Unter manchen Regeln gibt es keine Beispiele. Das ist ungewöhnlich. Entweder ist die Regel so offensichtlich, dass ein Beispiel Overkill wäre. Andererseits ist es gerade dann extrem leicht zu finden. Ich empfehle euch, zumindest so lange die Zeit zu investieren und ein Beispiel festzuhalten, bis ihr mehrere solcher User Stories erfolgreich implementiert habt und aus Erfahrung bestätigen könnt, dass das Beispiel wirklich keinen Mehrwert gebracht hat.

Oder die Regel ist so kompliziert oder unklar, dass es nicht gelungen ist, konkrete Beispiele zu nennen. Spätestens bei der Umsetzung müsst ihr ganz konkret werden. Besser ist es, vorher Klarheit zu schaffen, indem ihr die Beispiele ergänzt (nachdem ihr vielleicht die Regel verbessert habt).

Wie oft macht man Example Mapping und wer sollte teilnehmen?

Zum Thema Häufigkeit habe ich zwei Daumenregeln.

1. Lieber öfter und kürzer als seltener und ermüdend. Ein Team von mir hat sich gerne Dienstags und Donnerstags für 50 min zusammengesetzt. Für andere Teams sind 25 min alle zwei Tage ausreichend.
2. Die Rate sollte der entsprechen, mit der Stories bei euch fertig werden. Wird im Schnitt alle zwei Tage eine Story fertig, reicht eine erfolgreiche Session alle zwei Tage. Vermutlich solltet ihr in der Frequenz etwas Puffer einbauen, so dass ihr nicht Schwierigkeiten kommt, wenn ihr auf ein paar rote Riesen hintereinander trefft.

Besonders am Anfang ist es hilfreich, Example Mapping mit dem ganzen Team zu machen, so schafft ihr nebenbei auch ein gemeinsames Verständnis über die Methode. Später könnt ihr dann mit kleineren Gruppen experimentieren.

Pro-Tipp für Kleingruppen: Damit die Session erfolgreich sein kann, braucht ihr die relevanten Perspektiven am Tisch. Typischerweise sind das mindestens die 3 Amigos, also jemand mit Software Development Know How, jemand mit Testing Know How und ein „Produktmensch“. Abhängig von eurer Domäne kann eine andere Zusammensetzung sinnvoll sein. Manche Teams nehmen z.B. einen User Experience Designer mit dazu.

Wenn nicht alle im Team an dem Gespräch teilnehmen, stellt sich die Frage, ob und wie man die anderen inhaltlich mitnimmt. Vielen Teams ist hier viel gemeinsames Team-Verständnis wichtig, so dass sie sich z.B. in zwei Gruppen aufteilen, in jeder Gruppe eine Story mappen, und dann tauschen, wobei ein Teilnehmer bei der Story bleibt, um den Neuankömmlingen das Zwischenergebnis zu erklären.

Fazit

Example Mapping ist eine einfache Technik, mit der du schnell, lebendig und produktiv gemeinsames Verständnis zum Umfang und Inhalt von User Stories schaffen kannst. Im Gegensatz zu anderen Techniken wie Planning Poker identifiziert es Unklarheiten und unterschiedliche Ansichten direkt und nicht indirekt über divergierende Schätzungen. Deshalb passt es sehr gut zu extrem leichtgewichtigen Schätzmethoden wie der 3-Eimer-Schätzung. Product-Backlog-Refinement wird so wesentlich effizienter und macht auch mehr Spaß.

Bedanken möchte ich mich ausdrücklich bei Matt Wonne, der mit seinem Artikel „Introducing Example Mapping“ im Cucumber-Blog die Basis zu diesem Artikel gelegt hat.

Mehr erfahren über Example Mapping und viele andere hilfreiche Techniken kannst du übrigens in meinem Advanced Scrum Programm, das für Scrum Master über den A-CSM zum Certified Scrum Professional – SM führt und für Product Owner über den A-CSPO zum Certified Scrum Professional – PO.