User Story Mapping – Dokumentation war gestern, gemeinsames Verständnis ist heute

User Story Mapping – Dokumentation war gestern, gemeinsames Verständnis ist heute

Eine große Wand, viele Post-its, Stifte – los geht’s. Alternativ: Video-Call, simultaner Zugriff auf ein digitales Whiteboard – remote geht User Story Mapping auch.

Um erfolgreich User Stories zu „mappen“, braucht es nicht viel.

User Story Mapping, wer braucht das und vor allem – was ist das?

Alle, die an der Entwicklung, Erweiterung oder Optimierung von z.B. einer Service-Plattform, einer App oder einer anderen digitalen Lösung beteiligt sind, können vom Einsatz dieser Methode profitieren.

Wie der Name schon sagt, erstellt man beim User Story Mapping eine „Karte“. Diese Karte enthält zwei wesentliche Dinge:

Zum einen beschreibt sie den fachlichen Produktumfang aus Nutzersicht. Im Klartext: Beschriebene Post-its, die von links nach rechts angeordnet werden und darstellen, welche Funktionen und Features einem Nutzer zur Verfügung stehen und wie sie genutzt werden können. Zum anderen dient diese Karte, oder besser Map, als Gesprächsgrundlage. Das große Ganze, kleinste Details und die Zusammenhänge dazwischen werden sichtbar gemacht und können so besprochen werden.

Was ist der größte Vorteil dieser Methode?

Wir setzen uns längere Zeit mit unserer digitalen Anwendung auseinander, definieren ihre Anforderungen bis ins Detail, übergeben akribische Beschreibungen und finden heraus, dass es doch noch Raum für Interpretation gab. Mehr Dokumentation ist selten die Lösung und auch verbale Übergaben können dazu führen, dass die Beteiligten über eine blaue, eckige Form reden, aber an Dreieck und Quadrat denken.

Neben der inhaltlichen Auseinandersetzung mit Anforderungen, geht es bei der User Story Map um das Optimieren fehleranfälliger Projekt-Kommunikation. Wer also sichergehen will, dass eine digitale Anwendung bis ins Detail durchleuchtet wird und, dass alle vom gleichen sprechen, kommt am User Story Mapping nicht vorbei.
In seinem Buch zur Methode beschreibt Jeff Patton, wie man die Map und das Erzählen der User Stories nutzt, um zu einem nachhaltigeren gemeinsamen Grundverständnis zu kommen.

Wie genau geht man beim User Story Mapping vor?

Es gibt ein sehr schönes und leicht zugängliches Beispiel in besagtem Buch. Wir nennen es: Die Morgenroutine. Es verdeutlicht, wie man eine User Story Map anlegt, sich darüber austauscht, Zusammenhänge und Prioritäten verdeutlicht.

Schritt 1 – Der lineare Erzählfluss aus Sicht eines bestimmten Users

Wir schreiben auf Post-its was zu unserer Morgenroutine gehört und ordnen die einzelnen „Aktivitäten“ – dem Erzählfluss folgend – von links nach rechts an. Das heiĂźt links steht „Aufwachen“ und rechts vielleicht „Das Haus verlassen“.

Der lineare Erzählfluss aus Sicht eines bestimmten Users.
Der lineare Erzählfluss aus Sicht eines bestimmten Users.

 

Schritt 2 – Die Grundstruktur der User Story Map

Wir überprüfen, ob sich manche Aktivitäten vielleicht zusammenfassen lassen, da sie z.B. etwa zur gleichen Zeit passieren. Beispiele hierfür wären „Tee kochen“ und „Müsli zubereiten“ als Teilschritte, die sich unter der Aktivität „Frühstücken“ zusammenfassen lassen.
Auf diese Weise ergibt sich die Grundstruktur: Der „Backbone“ mit allen Aktivitäten und die darunter angeordneten Details.

Die Grundstruktur der User Story Map.
Die Grundstruktur der User Story Map.

 

Schritt 3 – Details, Alternativen und andere User

Bisher ging es nur um uns selbst, jetzt nehmen wir die Routine von anderen mit in unsere Map auf. Welche Alternativen gibt es in den Details – Toast statt MĂĽsli – und welche Aktivitäten kommen in unserer Routine nicht vor, sehr wohl aber bei anderen (z.B. „Trainieren“).

Details, Alternativen und andere User in der User Story Map.
Details, Alternativen und andere User in der User Story Map.

 

Schritt 4 – Gewünschter Outcome und Priorisierung

Wenn wir unsere Map auf diese Weise angereichert haben, können wir uns überlegen, nach welchen Kriterien wir die Bestandteile priorisieren wollen. Wenn wir alles was uns eingefallen ist, in unserer Routine belassen würden, wäre unser Morgen sehr lang und wir mit Toast und Müsli und allen anderen Optionen auch sehr satt.
Das Gedankenbeispiel aus Pattons Buch hat auch hier eine Lösung.
Was passiert mit all unseren Aktivitäten, wenn wir verschlafen? Was ist jetzt noch wichtig und muss passieren, bevor wir das Haus verlassen? Wir sind uns wohl einig, dass das Training ausfällt.

Unser „gewünschter Outcome“ ist jetzt „Das Haus in wenigen Minuten verlassen“. Um dies zu erreichen, müssen wir unsere Inhalte priorisieren. Hierfür ziehen wir horizontale Linien in unsere Map. Im ersten Bereich bleiben alle unsere „Wir haben verschlafen“ Aktivitäten und ihre notwendigen Details. In den zweiten verschieben wir die Aktivitäten, die zur „Normalen Routine“ gehören, in den dritten Bereich schieben wir all die Dinge, die z.B. zu „einem luxuriösen Morgen“ passen.

Der gewĂĽnschte Outcome und Priorisierung der User Stories.
Der gewĂĽnschte Outcome und Priorisierung der User Stories.

 

Was macht man mit diesem Ergebnis?

Bei PPW beschäftigen wir uns natürlich eher nicht mit der Morgenroutine unserer Kunden. Allerdings lassen sich über das beschriebene Vorgehen neue Produktideen, über die Jahre gewachsene Produkte oder auch neue Teilfeatures mit einfachen Mitteln in einem Gesamtbild darstellen. Man kann gemeinsam auf die Map schauen, auf Dinge zeigen und auf Basis dieses gemeinsamen Verständnisses zusammenarbeiten. „Aktivitäten“ stehen z.B. für Funktionsbausteine, die Priorisierung aus UX Sicht für erste testbare Feature Sets oder aus Entwickler Sicht für Releases.

Muss wirklich gar nichts mehr dokumentiert werden?

In erster Linie dient die erstellte Map als „Dokumentation“. Sie ist eure Konversationsgrundlage. Mit ihr könnt ihr andere in eure Überlegungen einweihen, auf die verschiedenen Bestandteile und Zusammenhänge schauen. So erzeugt ihr das gemeinsame Verständnis, auf das ihr mit dieser Methode abzielt.
User Story Maps eins zu eins zu verschriftlichen wäre demnach nicht zielführend. Gibt es also gar keine (zusätzliche) Dokumentation? Doch, die gibt es. Alles was abseits der Stories geschieht, sollte festgehalten werden. Führt ihr z.B. eine Diskussion zu den Optionen eines Features, solltet ihr nachhalten, warum ihr zu welcher Entscheidung gekommen seid. So vermeidet ihr es, Entscheidungen später in Frage zu stellen und Diskussionen doppelt führen zu müssen.

Welche Nachteile hat das User Story Mapping?

Je nach Sichtweise liegt der größte Nachteil der Methode wohl in ihrer Kerneigenschaft: Die Stories leben davon „erzählt“ zu werden. Schriftliche Versionen können ihnen nicht wirklich gerecht werden. Das heißt, dass sie nur schlecht ohne ihre „Erfinder“ überleben. Das klingt erstmal dramatisch. Hier geht es allerdings um die grundsätzliche Entscheidung für oder gegen die Methode. Wer nicht vor hat, die Map zum Kommunikationsmittelpunkt, zu einem lebenden Dokument, zu machen, sollte hier keine Energie verschwenden.

Fazit

Das User Story Mapping bietet Konzeptern, Designern, Entwicklern – eigentlich allen Projektbeteiligten – einen leicht zu erlernenden Weg, effizienter in Bezug auf Anforderungen miteinander zu kommunizieren. Sie erfordert Energie und Durchhaltevermögen, wenn man komplexe Zusammenhänge greifbar machen möchte. Aber genau dieser Einsatz rechnet sich, wenn man sich durch das Arbeiten mit einer User Story Map absichert und später in der Entwicklung nicht von dieser Komplexität eingeholt wird.

Titelbild von Tim Gouw auf unsplash