Story / Impact Mapping – Kontext, Prinzipien und Übersicht
Small-Batch-Softwareentwicklung ist gut
Es gibt viele Vorteile, wenn man bei der Softwareentwicklung den Small-Batch-Ansatz (viele kleine Einzelschritte) verfolgt:
- Schnelleres Feedback
- Probleme werden lokalisiert
- Verringertes Risiko
- Mehr Druck und Routine zur Aufwandsreduzierung
Naive Small-Batch-Softwareentwicklung ist nicht ganz so gut
Wenn man jedoch auf naive Art und Weise die Small-Batch-Softwareentwicklung angeht, gibt es auch einen bedeutenden Nachteil: den fehlenden Bezug zum Gesamtziel.
Jeff Patton hat dieses Phänomen anhand des Beispiels eines Baumes und eines Sacks voller Blätter beschrieben:
„Ich stelle mir einen Baum vor, dessen Stamm aus den Zielen und gewünschten Vorteilen besteht, die das System vorantreiben. Die dicken Äste sind die Nutzer, die dünneren Äste und Zweige sind die Capabilites, die sie benötigen. Die Blätter stellen die User Stories dar, die klein genug sind, um sie in den Iterationen zu entwickeln.
Nach all dieser Arbeit, nachdem wir so viel gemeinsames Verständnis aufgebaut haben, habe ich das Gefühl, dass wir alle Blätter vom Baum nehmen und in einen großen Sack stopfen – und den dann Baum fällen.“
Der „Sack voller Blätter” bezieht auf eine kontextfreie, priorisierte Liste von Aufgaben in einem Backlog und spiegelt das naive Verständnis für „Backlogs” wider, das meines Erachtens besonders für Agile-Anfänger typisch ist. Auch wenn es sich theoretisch so anhört, als sei es ein Small-Batch-Ansatz, wird bei dem „Sack voller Blätter” die Verbindung zu den zugrundeliegenden Prinzipien und Zielen getrennt und somit die Autonomie untergraben.
Die 5 Attribute eines effektiven Small-Batch-Ansatzes in der Softwareentwicklung
Ein effektiverer Ansatz geht jedoch noch über die Unterteilung in kleinere Einheiten hinaus. Ein effektiverer Ansatz:
- betont die eigentliche Intention mit Hilfe von Zielen.
- betont den logischen Zusammenhang zwischen den Zielen und den erforderlichen Aufgaben.
- stellt sichtbar die Ziele, Aufgaben und Zusammenhänge dar, um eventuelle Unstimmigkeiten und Missverständnisse aufzudecken.
- ist auf gemeinschaftliche Arbeit ausgerichtet.
- ist iterativ, d. h. zu Anfang ist keine Vollständigkeit erforderlich.
- Story/Impact Mapping vs. Small-Batch-Softwareentwicklung
Sowohl Jeff Pattons „User Story Mapping” als auch Gojko Adzics „Impact Mapping” sind (weitestgehend äquivalente) Antworten auf die naiven Ansätze zur Bestimmung der kleineren Einzelschritte in der Small-Batch-Softwareentwicklung (also für die Erstellung von Backlogs). Ich würde es folgendermaßen beschreiben:
Anmerkung: Dieser Impact Mapping Prozess sollte iterativ sein. Er ist hier nur für ein besseres Verständnis sequenziell dargestellt. Es ist weder notwendig noch empfehlenswert, jeden Schritt in dieser Reihenfolge durchzuführen. Stattdessen können Sie an dem Punkt anfangen, an dem Sie sich gerade befinden, und die Schritte ganz nach Bedarf austauschen.
1) Identifiziere Ziele
Was möchtest du erreichen?
Das sollte etwas sein, was man beobachten und somit auch messen kann. Aus diesem Grund mag ich den Begriff „Auswirkung”, denn das bedeutet, dass etwas messbar ist. Jedoch ist „Ziel” geläufiger und außerdem führe ich nicht gerne neue Begrifflichkeiten ein, wenn es nicht unbedingt nötig ist.
Es kann mehrere Ziele geben.
2) Rollen und Aktivitäten identifizieren
Wer muss an einer Aktivität teilnehmen, um die Ziele zu erreichen? Bzw. welche Aktivitäten müssen von jemandem ausgeführt werden, um die Ziele zu erreichen?
Generell fange ich am liebsten mit den Aktivitäten an. In der Praxis ist es aber doch eher ein ziemlich iterativer Prozess.
Bitte beachten Sie, dass „Rolle” nicht „Person” bedeutet. „Person” kann sich auf andere Rollen beziehen, die nichts mit Ihren Zielen und stattdessen vielmehr mit deren eigenen Zielen zu tun haben. Das bedeutet meistens, dass man zusätzliche Ziele hinzufügen muss, die unterstützt werden müssen.
3) Capabilities identifizieren
Was ist die Voraussetzung, damit die Rolle eine Aktivität durchführen kann?
Capabilities müssen nicht notwendigerweise etwas sein, was in die Software eingebaut ist.
4) Features und Stories identifizieren
Was muss getan werden, um Capabilities zu erschaffen bzw. möglich zu machen?
Stories sollten aus kleineren Arbeiten bestehen. Bei Features geht es eher darum, Diskussionen auf einem detaillierteren Level zu ermöglichen.
Dieser Text stammt aus dem Blog von Jason Yip und wurde von uns ins Deutsche übersetzt.
Lerne mehr über Story Impcat Mapping als Scrum Master
Unsere zertifizierten Trainer bieten Fortbildungen auf der ganzen Welt an und ermöglichen dir ein passgenaues Training für dein Anliegen.
Für Scrum Master bieten wir folgende Trainings und kostenlosen Fortbildungsmöglichkeiten: