Story Map

Wie sieht die innere Struktur unseres Produktes aus?

Bei dieser Praxis wechselt der Fokus von WAS ist unser Produkt zu WIE soll das Produkt aussehen. Wobei nicht nur die Benutzeroberfläche damit verstanden wird, sondern auch das (fachliche) Innenleben des Produktes. Dieses soll gemeinsam erarbeitet und priorisiert werden. Mit der Priorisierung wird auch die Frage beantwortet: Wie entwickelt sich unser Produkt?

Praktik und Beschreibung

Story Map

Als Praktik bietet sich hier eine Story Map an. Die Story Map orientiert sich am Kundenerlebnis und bildet auf dieser Basis die innere Struktur des Produktes ab. Nach einer Auslegeordnung und Sortierung in den Ablauf des Kundenerlebnisses kann das MVP aus der Story Map rausgeschnitten werden.

 

Ofmals zeigt es sich, das für die unterschiedlichen Personas unterschiedliche Story Maps nötig sind. Aus ist der der Produkt Owner stark gefragt, weil es jetzt um die Details des Produktes geht und dies mit diesem hereogenen Team auf einen gemeinsamen Nenner gebracht werden muss. Das Erstellen der Story Map ist Knochenarbeit und kann locker 3-4 Stunden in Anspruch nehmen.

 

Service Blue Print

Auf Basis der Story Map mit dem MVP kann ein Service Blue Print erstellt werden. Dieser visualisiert die systemtechnischen Aspekte des MVPs und bietet eine noch tieferen Einblick in das Produkt. Dies hilft oft das Verständnis zwischen den Fach- und die IT-Spezialisten für einander zu stärken.

Beispiel aus der Praxis

Mit einem Team aus der Medizinalbranche habe ich vor 8 Monaten die Iteration Zero durchgeführt und eine Story Map mit dem MVP erstellt. Wie immer war es Knochenarbeit und wir haben eine grosse Stellwand mit Post-It's produziert.

Das Team und der Produkt Owner haben die Story Map in ihrem Projektraum weiterhin präsent und schauen immer mal wieder darauf. Es gibt ihnen bei grundlegenden Diskussionen immer wieder Halt und hilft ihnen nicht vom Weg abzukommen.

Wichtige Frage dabei: Ist das wirklich im MVP enthalten? Falls nein, bitte unterhalb der Linie auf Post-It festhalten und dann wieder auf das wichtige, das MVP fokussieren!

Vor der Iteration Zero haben sie als Team bereits mehr als ein Jahr verbraten und immer wieder über Detail-Spezifikationen diskutiert und keine Einigkeit erhalten. Die Iteration Zero sowie die Story Map waren für sie gold richtig und werden sie höchstwahrscheinlich noch lange begleiten.

Was steckt dahinter?

Fokus auf Kunde und Kundenerlebnis

Eine Story Map soll immer ein Kundenerlebnis abbilden. Oft wird diese Praktik zuerst mit einem Projektstrukturplan verglichen, was es nicht ist. Bei der Story Map liegt der Fokus auf dem Kunden und seinem Erlebnis mit dem Produkt. Administrative oder koordinative Arbeiten haben nichts auf der Story Map verloren.

 

Wertschöpfungskette abbilden

Die Story Map bildet einen Ablauf des Kundenerlebnisses ab. Der Ablauf soll sich an der Wertschöpfungskette orientieren. Das Kundenerlebnis wird nicht im Detail sondern aus einer High-Level-Sicht dargestellt.

 

Grundlage für Aufbau der MVP Backlogs

Die Story Map zeigt die innere Struktur des Produktes. Daraus lässt sich anschliessend das Backlog mit den Epic’s und User Stories aufbauen. Aber Achtung: ein Zettel in der Story Map entspricht weder einer User Story noch einem Epic. Hier muss mit Erfahrung die Epic’s und User Stories rausgeschnitten werden.

 

Es braucht das ganze Team dazu

Der Aufbau einer Story Map mit dem ganzen Team ist sinnvoll, jeder im Team kann so das Produkt mitgestalten. Es braucht viel Zeit und Energie. Der Aufwand lohnt sich jedoch, da dann das ganze Team auch die innere Struktur des Produktes sehr gut kennt.

 

Alle können die innere Sturktur des Produktes mitgestalten

Jede Person im Team kann aktiv das Produkt gestalten, unabhängig davon welche Skills er hat. Ich höre oft von Mitarbeitenden z.B. aus der IT, dass dieses Mitgestalten für sie neu und sehr wertvoll ist. Es gibt der eigentlichen Arbeit einen ganz neuen Sinn und generiert eine unglaubliches Commitment vom Team zum Produkt.