Blog

User Story Mapping

Wer bereits öfter mit der IT Welt zutun hatte, dem sind Begriffe wie Agile Entwicklung, Scrum oder User Stories vermutlich nicht fremd. Und wer bereits an der Konzeption und Entwicklung von Software beteiligt war, der weiß, dass die Baustellen der Softwareentwicklung nicht erst mit der Entwicklung beginnen und dass das Scheitern von Softwareprojekten meist an der Planung des Projektes liegt.
Die Konzeption eines Softwareprojektes ist oft langatmig und in einigen Projekten findet man eine Reihe von Dokumenten vor sich, die unzählige Informationen enthalten, seien es Angebote, Grobkonzepte, Wireframes, Lastenhefte, Pflichtenhefte usw. Das kostet nicht nur viel Zeit, sondern auch Nerven und auch – oder gerade – bei einer Flut von Dokumenten bleiben Missverständnisse nicht aus.

Weniger ist manchmal mehr. Und bei der Softwareentwicklung gilt das insbesondere für die Anzahl und den Umfang unterschiedlichster Dokumente. Hier kommt die agile Entwicklung ins Spiel. Agile Entwicklung heißt jedoch nicht, gar nichts mehr zu dokumentieren und einfach drauf los zu programmieren, sondern viel mehr mit weniger Dokumenten, die kürzer gefasst und vor allen Dingen lesefreundlich sind, auszukommen.

Um den Prozess eines agilen Softwareentwicklungsprojektes zu optimieren und ein gemeinsames Verständnis der zukünftigen Software zu erhalten, ist der Einsatz von User Stories und User Story Mapping unser Weg zum Ziel.

Was sind User Stories?

Eine einzelne User Story ist das kleinste Element einer Geschichte. Sie beschreibt eine Aufgabe, die ein Nutzer mit einer Software erledigen kann und zwar in geringster Komplexität. Eine User Story ist in Alltagssprache formuliert und KURZ. Eine User Story passt auf einen Notizzettel oder eine Karteikarte.

Sie besteht maximal aus Titel und kurzer Beschreibung auf der Vorderseite und Akzeptanzkriterien auf der Rückseite.

Akzeptanzkriterien sind Kriterien, welche die erfolgreiche Umsetzung einer User Story überprüfen. Erst bei Erfüllung aller Akzeptanzkriterien einer User Story gilt diese als abgeschlossen. Eine User Story besteht in der Regel aus drei bis vier solcher Kriterien. Sollte die Liste länger ausfallen, bedeutet das, dass die User Story nicht klein genug ist.

Eine User Story ist nur dann klein genug, wenn sie auf eine Karteikarte passt!

Ein Beispiel für eine User Story:
„Als Redakteur möchte ich meinen zuletzt bearbeiteten Artikel sehen, um Zeit bei der erneuten Suche zu sparen.“

Nachdem bereits eine Reihe User Stories geschrieben wurden, haben wir nun einen Stapel voller Karteikarten und Notizen. Und jetzt?

User Story Mapping

Etliche User Stories führen uns noch nicht zum Ziel. Mit User Stories wollen wir einzelne Geschichten erzählen. Wir müssen jedoch den Überblick über die einzelnen Aufgaben und die Komplexität des gesamten Softwareprojektes behalten. Hier kommt das User Story Mapping ins Spiel.

Das User Story Mapping lebt von der Kommunikation innerhalb des Projektteams.
Zunächst werden alle User Stories gemeinsam in eine grafische Übersicht gebracht.
Hierfür werden folgende Schritte durchlaufen:

  1. Allgemeine „Kapitel“ (Epics) wählen
  2. Kapitel-Karten horizontal anordnen
  3. Die User Stories Ihren Kapiteln zuordnen und wenn möglich in Reihenfolge vertikal unterhalb des Kapitels anordnen

Klingt einfach? Ist es im Grund auch.

Haben wir alle vorhandenen User Stories zugeordnet, beginnen wir von vorne und besprechen gemeinsam im Team die einzelnen Stories. Hierdurch erreichen wir ein gemeinsames Verständnis der User Stories und welche Anforderungen diese erfüllen sollen.

Vielleicht kommt nun folgender Gedanke auf: „Wenn ich doch schon all meine Anforderungen in solch kleine Module aufgeteilt habe, wozu ist es dann noch notwendig diese Punkte zu besprechen?“

Um ein Produkt zu entwickeln, müssen wir die Geschichte als Ganzes verstehen. Ein einfaches Herunterschreiben von Anforderungen genügt nicht, um am Ende ein Produkt zu haben, welches den gewünschten Anforderungen entspricht. Wenn wir Unmengen von Anforderungen aufschreiben und wir in einem größeren Team arbeiten, sind Missverständnisse nicht zu vermeiden. Die Anforderungen werden von den Projektbeteiligten unterschiedlich verstanden und umgesetzt und das passiert auch bei denkbar einfach klingenden User Stories. Daher ist der Kernpunkt beim User Story Mapping die Kommunikation des Teams. Nur durch die Kommunikation werden unterschiedliche Ansichten deutlich und neue Ideen geboren. Und nur durch Kommunikation kann das Endergebnis den Vorstellungen des Kunden entsprechen.

Wie sieht eine User Story Map aus?

In unserem simplen Beispiel für eine User Story Map, wird beim genaueren Hinsehen schon deutlich, dass denkbar einfache Anforderungen bereits viele Fragen aufwerfen.

Beispiel: „Artikel im Warenkorb bearbeiten“ – Was genau versteht der Kunde unter Bearbeiten? Möchte er die Anzahl des Artikels verändern können, möchte er den Artikel aus dem Warenkorb wieder löschen können, oder ihn vielleicht als Geschenk markieren oder auf die Merkliste setzen?

Diese Punkte müssen klar definiert werden und sollten als Akzeptanzkriterien hinzugefügt werden. Unter Umständen bedeutet das, dass diese User Story zu groß ist und in weitere User Stories aufgeteilt werden muss.

Fazit

Das User Story Mapping ist in unseren Augen der Weg zum Ziel, wenn es um wirklich gute Softwareentwicklung geht. Kommt man in kleineren Projekten noch ohne aus, ist das User Story Mapping für größere Projekte eine unumgängliche Variante für zufriedene Anwender, einen zufriedenen Kunden und zufriedene Dienstleister.

Masiar IghaniUser Story Mapping