"Example Mapping": Ein Mittel gegen typische Pain-Points in agilen Teams?

Typische Pain-Points in der agilen Softwareentwicklung

Agile Entwicklung bringt viele Vorteile, doch es gibt einige wiederkehrende Schmerzpunkte im Alltag agiler Teams. Folgende kenne ich aus eigener Erfahrung:

• Unklare Akzeptanzkriterien
  User-Storys enthalten oft vage oder unvollständige (aus “projekttechnischen Gründen” manchmal überhaupt keine) Abnahmekriterien. Die Folge: endlose Diskussionen im Refinement, Unsicherheit darüber, wann eine Story wirklich “Done” ist, und ein hohes Risiko von Missverständnissen und Nacharbeiten in späteren Phasen.

• Missverständnisse zwischen Business und IT
  Fachabteilung und Entwickler reden häufig aneinander vorbei. Anforderungen werden unterschiedlich interpretiert, was spätere “Das habe ich anders gemeint!”-Momente im Sprint Review nach sich zieht. Wichtige Aspekte bleiben unentdeckt, weil eine gemeinsame Sprache fehlt.

• Unklare, verspätete oder gänzlich fehlende Testfälle
  Tester werden oft erst spät in die Feature-Definition einbezogen. Testfälle werden unter Zeitdruck kurz vor Release erstellt – oder es kommen Bugs ans Licht, weil Test-Szenarien übersehen wurden. Ohne klare Beispiele weiss das QA-Team nicht genau, welche Szenarien und Testdaten relevant sind. Es mag sogar bereits in Betrieb befindliche “Legacy”-Funktionalität geben, die “unter dem Tester-Radar” oder vor der Einführung agiler Methoden implementiert wurde und für die keine Regressionstests vorliegen.

• Kein gemeinsames Verständnis im Team
  Wenn Entwickler, Tester und Product-Owner nicht früh miteinander reden, entstehen Silos. Jeder hat ein anderes Bild vom Scope der Story. Es fehlt ein geteiltes Verständnis und eine einheitliche Begriffswelt, an der sich alle orientieren können. Je länger dieser Zustand anhält, umso “besser” werden die Silobetreiber darin, mit ihm umzugehen und das Unheil nimmt seinen Lauf, in Gestalt falscher Entscheidungen und aufgebauter technischer Schulden …

• Absinken der Qualität von Meetings
  Langwierige, ermüdende und unstrukturierte Meetings können ein Symptom für mangelnde Informationen sein. “Meeting-Hijacking” wird zur beliebten aber ineffizienten Strategie, um oberflächliche Klärung herbeizuführen, für die es Vertreter von Business, Entwicklung und Testing an einem Ort braucht.

Eine Technik, die genau hier ansetzt, habe ich kürzlich auf einem Projekt kennen (und lieben) gelernt und möchte sie gerne in diesem Artikel vorstellen: Example-Mapping (EM).

Was ist Example-Mapping?

EM ist eine schlanke, kollaborative Methode, mit der vor allem agile Teams User-Storys gezielt verfeinern und klare, überprüfbare Akzeptanzkriterien entwickeln können. Sie kann aber auch in verwandten Szenarien verwendet werden, wie zum Beispiel für die nachträgliche Erstellung von manuellen oder automatisierten Regression-Sets für “Legacy”-Applikationen. Das zugrunde liegende Konzept der “Specification-by-Example” unterstützt und fördert agile und DevOps Prinzipien.

Die Methode stammt aus dem Kontext von Behavior-Driven Development (BDD) wo sie zusätzliche Vorteile ausspielen kann: Die in EM-Sessions erarbeiteten Beispiele lassen sich nahtlos in „Given-When-Then“-Szenarien übersetzen.

Der Ansatz basiert auf einer einfachen Idee: Für jede Story werden durch die Teilnehmer gemeinsam Geschäftsregeln, konkrete Beispiele und offene Fragen strukturiert visualisiert. Dadurch wird jede Story nicht nur greifbarer, sondern auch überprüfbar.

Um die Vollständigkeit möglichst sicher zu stellen, handelt es sich bei den Teilnehmern um Vertreter aus Business, Entwicklung und Test (häufig die “Three Hats” oder “Three Amigos” genannt).

Wie führe ich eine EM-Session durch? (s. auch Artikel von Matt Wynne vom 08.12.2015)

Vorbereitung

Teilnehmer benachrichtigen: drei Rollen (s. “Three Hats” oben), möglichst mindestens eine Person pro Rolle Meetingraum und -utensilien vorbereiten - Raum mit Whiteboard + Post-Its in gelb/blau/grün/rot oder Online-Sitzung vorbereiten - ein Miro-Template habe ich hier vorbereitet (einfach in eigenen Workspace kopieren und dort weiterbearbeiten).

vorbereitetes Miro-Template vorbereitetes Miro-Template (Link hinterlegt) Timer setzen. Das Meeting sollte für 20-30 Minuten eingeplant werden (“timeboxed”). Wichtig: sicherstellen, dass die zu behandelnden Storys, zumindest grob, vor dem Meeting bekannt sind.

Durchführung

• Gelb – User-Story: Die erste Story wird zunächst auf einer gelben Karte notiert und bildet die Überschrift der Session.
• Blau – Regeln: Wichtige Geschäftsregeln oder vorab bekannte Abnahmekriterien schreibt man auf blaue Karten (jede Regel auf eine Karte) und legt sie unter die Story. Diese Regeln umreissen, woran man erkennt, dass die Story erfolgreich umgesetzt ist.
• Grün – Beispiele: Für jede Regel sammelt das Team konkrete Beispiele oder Szenarien auf grünen Karten. Diese Beispiele illustrieren die Regel und liefern Kontext. Sie bilden konkrete Abnahmetests, an denen man später prüfen kann, ob die Regel erfüllt ist.
• Rot – Fragen: Alle offenen Fragen oder Unklarheiten, die während der Diskussion auftauchen und nicht sofort beantwortet werden können, kommen auf rote Karten. So gehen sie nicht vergessen und das Team verzettelt sich nicht in Spekulationen.

Während des Meetings sollte beobachtet werden, ob jede Story ein ausgewogenes Verhältnis von Regeln, Beispielen und Fragen hat.

• Wer nur rot sieht (Fragen), hat unter Umständen noch nicht das notwendige Know-How, um mit der Umsetzung der Storys zu beginnen.
• Ein starker blauer Einschlag (Regeln) zeugt von Komplexität. Kann die Story wirklich innerhalb eines Sprints abgeschlossen werden? Entspricht sie der akzeptierten Definition-of-Ready (DoR) des Teams? Hier kann eine Aufteilung in mehrere Storys sinnvoll sein.
• Allzu ausgedehnte Grünflächen (Beispiele) können Hinweise auf zu allgemein gefasste Regeln sein. Für die Übersicht, Verständnis und Qualität allgemein, könnte das Ergänzen von Regeln sinnvoll sein.

Nachbereitung

Hier sollte mit den Teilnehmern kurz aufgenommen werden, was gut lief und was in zukünftigen Sessions Verbesserungspotenzial bietet:

Eingangsstorys - sollte die Qualität der Storys die Grundlage für das Meeting sind angepasst werden (“DoR für die EM-Session”)? Teilnehmerkreis - sind alle “drei Hüte” adäquat vertreten? weitere Effizienz/Effektivität steigernde Massnahmen

Beispiel für das Example-Mapping einer Story (Büroventilator-Bedienung, ebenfalls über Miro-Link verfügbar) Aus aktuellem Anlass: das Beispiel eines Example-Mapping für die Bedienung eines Büroventilators

Erfolgsfaktoren für die Nutzung und Stolperfallen

Methodenfetischismus ist fehl am Platz. Trotzdem muss vor individuellen Anpassungen berücksichtigt werden, dass der Ressourcen-Fussabdruck der Methode in der Standardversion bereits auf ein Minimum abgespeckt ist. Somit sind bei Anpassungen die jeweiligen Risiken und die Auswirkungen auf das Return-On-Investment der Methode abzuschätzen. Einige Beispiele:

• keine Vorbereitung der Storys vor dem Meeting - Folge: der inhaltliche und zeitliche Rahmen des Meetings wird verwaschen - Risiko: Ergebnisse büssen Qualität ein, kostspielige Folgemeetings oder Nacharbeiten werden notwendig.
• Länge der Session nicht “Timeboxed” - Folge: was einmalig Sinn machen kann, hat bei Wiederholung negativen Einfluss auf die Beteiligung der Teilnehmer und macht den Vergleich von Sessions untereinander (Lernzyklen) schwieriger. - Risiko: Qualität und Return-on-Investment (ROI) der Methode sinken.
• inkonsequente Berücksichtigung der “Three Hats” - Folge: das gleichzeitige Tragen mehrerer Hüte führt (wie im echten Leben) zu fragwürdigen Ergebnissen, ebenso, wie das Tragen einer unangemessenen Hutgrösse. Wichtige Regeln werden nicht identifiziert - als “vernachlässigbare Edge-Cases” wahrgenommene Beispiele verursachen später in Produktion exorbitante Kosten - Risiko: Bugs, Nacharbeiten.

Sora findet, dass dieser Hut zu gross ist. Viele Eltern wären anderer Meinung.

Nutzen des EM für verschiedene Rollen

Für den Fall, dass es noch an Argumenten für die Anwendung mangeln sollte, nachfolgend einige Vorteile aufgelistet aus der Perspektive verschiedener Rollen in einem agilen Setting.

• Tester (QA) – Klarere Kriterien, weniger Bugs Für Testerinnen und Tester sind die Resultate eines EM sehr wertvoll: klare Abnahmekriterien und greifbare Beispiele liegen bereits vor der Implementierung vor. Das macht die Testfall-Erstellung einfacher und zielgenauer – und es werden seltener wichtige Edge-Cases übersehen. Weil alle Annahmen und Unklarheiten schon im Refinement besprochen werden, reduziert sich das Risiko (Produkt aus Eintrittswahrscheinlichkeit und Auswirkungen) späterer Defects erheblich. Mit EM wird die QA zum Mitautor der Abnahmekriterien: Tester bringen ihre Sicht ein, stellen Fragen und sorgen so dafür, dass Qualität von Anfang an mitgedacht wird. Hiervon profitieren besonders Organisationen mit “Herausforderungen in der Fehlerkultur”. Das Ergebnis sind weniger Bugs kurz vor dem Release und ein Testprozess, der deutlich stabiler läuft.

• Testmanager – Geringeres Risiko und bessere Planbarkeit Aus Sicht eines Testmanagers (eine Rolle, die in der agilen Welt kurz vor der Obsoleszenz steht) zahlt EM direkt auf Qualität und Risiko-Reduktion ein. Potenzielle Probleme oder Lücken in den Anforderungen werden hinreichend früh aufgedeckt, damit möglichst keine kostspieligen Fehler in Entwicklung und Test entstehen und der Testmanager nicht gezwungen ist, hektische Last-Minute-Fixes zu managen. Ähnlich wie für Tester, müssen Testmanager weniger ihrer Zeit für die Folgen des “Finger-Pointing” verschwenden. Statt Schuldzuweisungen wie “Der Tester hat nicht alles geprüft” oder “Die Entwickler haben es falsch gebaut” ziehen alle an einem Strang, weil von Anfang an klar ist, was gemeint ist. Für Testmanager bedeutet das also: zuverlässigere Qualität, planbarere Tests und ein Team, das Qualität als gemeinsame Verantwortung versteht.

• Testautomatisierer – Schneller von Beispielen zu automatisierten Tests Mitarbeitende, die für die Testautomatisierung zuständig sind, profitieren enorm von den im EM erarbeiteten Beispielen. Jedes grüne Karten-Beispiel lässt sich direkt in einen Testfall überführen – oft sogar in Form eines BDD-Szenarios (Given/When/Then) in einen Acceptance-Test und unter (KI-)Umständen sogar ohne nennenswerten Aufwand. Statt auf vage Anforderungen zurückzugreifen, kennt der Testautomatisierer genau die Geschäftsregeln und Randfälle, die getestet werden müssen und kann auch für die Testfallwartung auf die zentral abgelegten EM-Informationen zurückgreifen. Das beschleunigt die Automatisierung, da weniger Rückfragen nötig sind und erhöht die Relevanz der erzeugten Artefakte. Insbesondere, wenn die Automatisierungsteams nicht oder nur eingeschränkt organisatorisch integriert sind und sich sonst ihr eigenes Test-Orakel aufbauen müssten.

• Entwickler – Weniger Nacharbeit durch gemeinsames Verständnis Entwicklerinnen und Entwickler schätzen EM vor allem, weil es Klarheit schafft und spätere Nacharbeit reduziert. Im “Three-Hats”-Workshop sitzen sie mit am Tisch, stellen Fragen und hören die Perspektive des Product-Owners und der Tester. Dadurch werden viele Annahmen schon vor dem ersten Codeschnipsel geklärt, statt erst im Review oder während der Implementierung. Die grünen Beispielkarten geben den Entwickelnden ein präzises Bild, was gebaut werden soll und worauf es ankommt – Missverständnisse im Sprint werden seltener. Das bedeutet: weniger Fehlentwicklungen, weniger Bugfixing-Schleifen und insgesamt ein ruhigerer Sprintverlauf. Ausserdem hilft EM dem Team, überdimensionierte Storys früh zu erkennen und zu splitten. So landet keine „Big Fat Story“ im Sprint, die dann kurz vor Sprintabschluss explodiert und alle in Panik versetzt. Für Entwickler heisst das konkret: besser planbare Sprints und höhere Wahrscheinlichkeit, dass eine Story auf Anhieb die Erwartung trifft.

• Business/Product-Owner – Gemeinsame Sprache und geteilte Vision Die Fachseite – ob Product-Owner oder Business-Stakeholder – profitiert vielleicht am stärksten. Das EM bietet einen Rahmen, in dem ihre Anforderungen und der Kontext der Story zusammenhängend gehört und verstanden werden, ohne endlose Meetings. Im EM kann der Product-Owner seine Geschäftsregeln und Ziele erklären, während das Team sie in konkrete Beispiele übersetzt – alle sprechen über dasselbe in einer gemeinsamen Sprache. Das minimiert die Gefahr, dass am Ende etwas geliefert wird, das nicht den Erwartungen entspricht. Gleichzeitig erleben Business-Vertreter, dass diese Refinements kurz und fokussiert sind: Eine 25-Minuten-Timebox und klare Struktur halten sogar vielbeschäftigte Fachexperten bei Laune. Aus Product-Owner-Sicht sorgt die Methode auch für Sauberkeit im Backlog: Storys, die noch zu unklar oder zu gross sind, werden identifiziert und gar nicht erst in den Sprint gezogen. Damit gibt es weniger späte Überraschungen und Nacharbeiten. Unterm Strich schafft EM Vertrauen – das Business sieht, dass das Entwicklungsteam die Sprache des Fachbereichs spricht und echte Shared Understanding entsteht. Das Resultat sind bessere Lösungen, hinter denen alle stehen. Ansätze, die in Richtung “Living Documentation” und BDD (Beispiel: Serenity ) gehen, ermöglichen die automatisierte Generierung von Spezifikationen auf Basis der EM-Szenarien, was das Erstellen “toter” Confluence-Seiten ersetzen kann und den ROI des EM weiter nach oben treibt.

Warum ist in dem Artikel “KI” nicht erwähnt worden?

Dies bitte ich zu entschuldigen. Selbstverständlich ergeben sich auch in diesem Kontext Einsatzmöglichkeiten für den Einsatz der künstlichen Intelligenz, die individuell, je nach Themengebiet, Teamzusammensetzung und -Know-How (inkl. Prompting-Skills) sowie den in der Organisation definierten Nutzungsrichtlinien abweichen werden.

Im Miro-Template (Link siehe oben) ist für die Vorbereitung ein Prompt-Beispiel der Miro-KI enthalten, mit einem Vorschlag wie zugehörige Regeln, Beispiele und Fragen aussehen können. In manchen Teams wird die Nutzung von KI unnötig den Horizont schmälern, in anderen Teams kann sie helfen, die Teilnehmer rasch auf “Betriebstemperatur zu bringen” (beispielsweise indem unsinnig scheinende Promptresultate zusammen identifiziert werden).

Während der Durchführung können die erstellten Inhalte rasch in die KI eingegeben werden, um auf Vollständigkeit geprüft, korrigiert oder übersetzt zu werden.

Fazit

“Example Mapping” adressiert einige der häufigsten Stolpersteine in agilen Teams – von unklaren Anforderungen bis zu späten Bugs – mit einer einfachen, moderierten Unterhaltung der “Three Hats” zur richtigen Zeit. Die Methode ist praxisnah und sehr schlank: ein bisschen Vorbereitung, bunte Karten (oder ein digitales Board) und 25 Minuten Zeit genügen üblicherweise, um eine Story deutlich schärfer zu machen.