Impact Mapping

Was ist Impact Mapping?

Wir bei databinding sind der Überzeugung, dass Transparenz und Nachvollziehbarkeit die Kernelemente sind für erfolgreiche Projekt-Ergebnisse. Wie ihr bei unseren Dienstleistungen bestimmt schon gelesen habt, machen wir uns bei agilen Vorgehensweisen verschiedene Methoden und Techniken zunutze. Eine davon ist das Impact Mapping. Darauf werde ich heute näher eingehen und euch einen Einblick geben, was das für unsere alltägliche Arbeit bedeutet.

Impact Mapping – die Theorie

Kurz und knapp zusammengefasst ist das Impact Mapping ein strategisches Planungsinstrument aus der agilen Software Entwicklung, um alle Teamaktivitäten dem übergeordneten Geschäftsziel auszurichten. Das Geschäftsziel bildet das Zentrum und gibt Orientierung durch den ganzen Projektprozess hindurch, woran wir arbeiten respektive weshalb es wichtig ist. Es wird von allen Beteiligten erarbeitet, ähnlich eines Mindmaps, und stellt die Kommunikation ins Zentrum. Eine effiziente Vorgehensweise mit schnellen Ergebnissen. Es fördert die Kommunikation und das Verständnis zwischen dem Projektteam und Stakeholdern. Zudem hilft es dem Team verschiedene Möglichkeiten zur Erreichung des Geschäftsziels zu evaluieren.
Die verschiedenen Möglichkeiten werden bewertet und nach Prioritäten aufgeteilt. Die Anforderungen beschreiben, was der Kunde oder die Interessenvertreter vom System erwarten, es definiert jedoch nicht, wie der Entwickler es umsetzen muss.
Die Impact Map stellt einen dynamischen Prozess durch das ganze Projekt hindurch dar, es wird ständig überarbeitet, verändert und ermöglicht so möglichst schnell auf geänderte Anforderungen und Rahmenbedingungen zu reagieren. Wenn sich zum Beispiel ein Geschäftsziel ändert, dann sind die Auswirkungen auf das System transparent ersichtlich, es braucht dazu keine aufwändige Dokumentation.

Die Abbildung zeigt eine Impact Map in Form eines Mindmap. Als Geschäftsziel ist IT-Kosten senken definiert, welche mit den zwei Interessenvertreter Head of IT und Tester verknüpft ist. Als Impact gibt es Knoten wie Qualität verbessern für den Interessenvertreter Tester und Wiederkehrende Aufgaben automatisieren vom Head of IT. Es werden Lieferobjekte wie Build Pipeline und automatisierte End to End Tests definiert. Die Build Pipeline ist das Ergebnis des Impact Wiederkehrende Aufgaben automatisieren. Autmatisierte End to End Tests ebenfalls. Bei letzeren kommt auch eine Verbindung von Qualität verbessern. So wird auch ein Zusammenspiel zwischen Head of IT und Tester ersichtlich.
Beispiel einer Impact Map

Die 4 Ebenen einer Impact Map

Warum – das Ziel?

Der Ausgangspunkt eines jeden Impact Maps ist das strategische Geschäftsziel. Diese Frage ist zugleich auch die wichtigste, da sie Orientierung gibt und man so das Ziel nie aus den Augen verliert. Warum wollen wir das tun? Weshalb ist das wichtig für uns?

Wer – die Interessenvertreter?

Welche Personen sind alle in diesem Projekt von Bedeutung? In welchem Verhältnis stehen die Akteure zum Geschäftsziel? Wer sind helfende und wer behindernde Akteure? Wie gehen wir mit Zielkonflikten um? Alles Fragen, die als Grundlage dienen.

Dieser Punkt kann im klassischen Projektmanagment mit einer Stakeholderanalyse verglichen werden. Projektrisiken sind bereits lokalisierbar.

Wie – welche Auswirkungen?

Auswirkungen (=Impact) und Anforderungen werden hier analysiert. Welche Anforderungen haben die Akteure an das Geschäftsziel?

Was – die Lieferobjekte?

Was sind die lieferbaren Ergebnisse? Welche Funktionen sind nötig? Das sind erste Epics, Features und User Stories und bilden die Basis für das Backlog.

Die Anwendung

Das Impact Map wird, wie schon beschrieben, kontinuierlich ergänzt und bearbeitet. Das garantiert die Konzentration auf die notwendigen Funktionen und gleichzeitig das Verständnis zwischen den Akteuren. Jede Funktion ist mit dem Geschäftsziel verbunden und belegt somit ihre Notwendigkeit. Die Ergebnisse müssen für das ganze Team sichtbar und verständlich sein, um Annahmen und Mehrdeutigkeiten während der Realisierung zu vermeiden. Ein zusätzlicher Pluspunkt ist hier, dass ein gemeinsames fachliches Verständnis für das zu entwickelnde Produkt aufgebaut wird und keine Begriffe aus dem Fachjargon benutzt werden müssen.

Eine andere Möglichkeit vorzugehen besteht darin von der 4. Ebene aus zu starten. Das ermöglicht zu sehen, welche Features wirklich notwendig sind und wo noch Defizite bestehen.

Weiteres Vorgehen

Die Aufgaben werden nun priorisiert und sortiert. Steht das Impact Map und die priorisierten Aufgaben, kann mithilfe einer Story Map und User Stories die detaillierte Planung beginnen. Eine User Story spiegelt dabei die erarbeiteten Punkte aus der Impact Map wieder.

Die Abbildung zeigt eine abgeleitete User Story für das Lieferobjekt Build Pipeline. Text: Als Head of IT möchte ich eine Build Pipeline damit ich wiederkehrende Aufgaben automatisieren kann.
Beispiel einer abgeleiteten User Story

Was wir bei der Anforderungserhebung noch so beachten, erfährst du im Beitrag Das Kano-Modell.