Читать книгу Roadmap durch die VUCA-Welt - Dennis Willkomm - Страница 38

In vielen agilen Teams und Unternehmen verwendet man User StoriesUser Stories, um Anforderungen aus Kundensicht zu beschreiben. Das klassische Anforderungsmanagement versucht, klare Beschreibungen mit möglichst vielen Details vom Kunden zu bekommen. Diese werden dann in Lasten- und Pflichtenheften vertraglich festgelegt. Im Gegensatz zu klassischem Anforderungsmanagement ist im agilen Umfeld zu erkennen, dass die Anforderungen erst einmal technisch sehr unspezifisch formuliert werden. Dafür wird aber stets die Perspektive des Kunden eingenommen und die technische Lösung später gemeinsam entwickelt.

Ron JeffriesJeffries, Ron, einer der drei Väter des Extreme Programming, schlug schon 2001 den sehr populären 3C-Ansatz vor. Diese drei C stehen für Card, Conversation und Confirmation.

Card (Karte) soll daran erinnern, dass eine User Story auf eine kleine Karteikarte passen soll. Es soll eben bewusst nicht zu viel analysiert und spezifiziert sein. Details und konkrete Lösungswege sollen in einer Zusammenarbeit des Teams entstehen. Dafür steht das zweite C, Conversation (Konversation, Gespräch). Hier kommt das Team zusammen und spricht über die User Story, nimmt sie auseinander, schneidet sie kleiner, bringt neue Ideen ein. Schließlich kommt es zum dritten C, der Confirmation (Bestätigung). Hier wird noch einmal sichergestellt, dass die Ziele der Konversation auch erreicht wurden, also ein Verständnis für das Problem und mögliche Lösungsansätze vorhanden sind. Hier werden oftmals Akzeptanzkriterien auf die Rückseite der Karte geschrieben. Diese dienen dazu, sich schon vor Beginn der Umsetzung Gedanken zu machen, was genau das fertige Produkt leisten muss, damit es die User Story erfüllt.

Eine User Story ist bei ihrer Formulierung aus Sicht des Kunden beschrieben und liefert Antworten auf die folgenden Fragen:

 Wer möchte etwas? (Rolle)

 Was wird benötigt? (Funktionalität)

 Wozu wird es benötigt? Welches Ziel soll erreicht werden oder welches Problem gelöst werden? (Wozu)

Zwar gibt es keine Vorgabe, wie eine User Story zu formulieren ist, allerdings hat sich unter Anwendern das Connextra-Muster etabliert, das User Stories in der folgenden Form vorschlägt:

Als <Rolle> möchte ich <Funktionalität/Ziel/Wunsch>, um <Nutzen/Warum>.

Im klassischen Anforderungsmanagement wird oftmals der Grund, warum etwas benötigt wird, nicht mittransportiert. Es entsteht eine sehr starke Fokussierung auf die konkreten und spezifizierten Anforderungen und bei der Lieferung der Lösung merkt man erst, dass das Problem nicht ganzheitlich verstanden wurde. User Stories helfen durch die Art ihrer Formulierung dabei, erst das Problem zu verstehen und erst dann gemeinsam nach Lösungen zu suchen.

Damit User Stories in einer Iteration von maximal vier Wochen auch erledigt werden können, müssen sie oftmals in kleinere Pakete unterteilt werden. Dafür gibt es eine ganze Reihe von hilfreichen Techniken. Ein Hilfsmittel zum sinnvollen Zerteilen der Stories ist die User Story Map, die durch Jeff Patton populär wurde (Patton/Economy 2015).

Beim sogenannten User Story Mapping arbeitet wieder das ganze Team zusammen. Ziel ist es, eine grobe Story (oft auch Epic genannt) zu verfeinern und in einer Art Landkarte darzustellen, die zum einen Teilaspekte sichtbar macht, zum anderen aber auch mögliche Versionen des Produkts, die man nacheinander veröffentlichen könnte.

An einem Beispiel von Jeff Patton können Sie sehr schön sehen, wie eine User Story Map aufgebaut wird und wie man damit arbeiten kann. Unsere kleine Abwandlung dieses Beispiels lautet: „Als VUCA-Held möchte ich mein Haus verlassen, damit ich zu meiner Arbeit gehen kann“. Dies stellt Ihr Epic dar. Jetzt dürfen alle Teammitglieder auf Karten notieren, welche Tätigkeiten ihrer Meinung nach durchgeführt werden müssten, um die Wohnung morgens zu verlassen. Diese können auch gleich als User Story formuliert werden. Im Anschluss schauen Sie sich an, welche User Stories entstanden sind und ob sich hier grobe Kategorien bilden lassen. Sie könnten zum Beispiel Stories zusammenfassen, die sich mit Kaffeekochen, Frühstücken oder Pausenbrote schmieren befassen. Dies könnte eine Kategorie „Verpflegung“ sein. Der morgendliche Ablauf könnte beispielhaft aus „Aufstehen“, „Hygiene“, „Verpflegung“, „Packen“ und „Verlassen“ bestehen. Dies stellt einen groben Ablauf dar und wird von Patton als „Backbone“ bezeichnet. Sozusagen ein Grundgerüst, dem sich die konkreten Stories zuordnen lassen.

Schauen Sie sich nun einmal die User Stories an, die vom Team zusammengetragen wurden. „Als Ehemann schalte ich den Wecker aus, damit meine Frau noch ein wenig weiterschlafen kann“, könnte eine mögliche Story sein. Ein anderes Teammitglied könnte eine Story hinzufügen, die in etwa so aussieht: „Als Hundebesitzer gehe ich eine schnelle Runde Gassi mit meinem Hund, damit dieser es aushält, bis ich wieder nach Hause komme“. An dieser Stelle können Sie sehen, dass es unterschiedliche Zielgruppen für das zu entwerfende Produkt geben kann. Das hilft dabei zu überlegen, ob eine erste Version des Produktes vielleicht nicht erst für die wichtigste Zielgruppe erstellt werden sollte.

Ein wichtiger Aspekt im agilen Umfeld ist das schnelle Gewinnen von Feedback. Dafür ist es hilfreich, sich zu überlegen, was minimal vorhanden sein müsste, damit man ein erstes Feedback von Anwendern bekommen könnte. Dafür überlegen Sie sich einen minimalen Anwendungsfall, der für sich genommen schon einen Mehrwert bringt. Stellen Sie sich vor, Sie bekommen nun die Information, dass Sie verschlafen haben. Aber es ist ein ganz besonderer Tag, denn in fünf Minuten kommt ein Taxi, das Sie abholen und zum Flughafen bringen soll. Sie haben einen wichtigen Termin mit einem Kunden, den Sie auf keinen Fall verpassen dürfen. Welche der User Stories aus unserem Beispiel ist nun noch von Belang, damit Sie das Haus innerhalb von fünf Minuten verlassen können? In einer solchen Situation wird wahrscheinlich ein Großteil der Stories unwichtig erscheinen.

Diese minimale Variante der User Story wird MVP (minimum viable product), das minimal funktionsfähige Produkt, genannt. Patton sieht das MVP als den minimalen Stand an, zu dem man sich schnellstmöglich Feedback einholen kann. Das heißt nicht, dass man hier auch schon ein zu kommerzialisierendes Produkt hat. Dieser Schritt folgt erst darauf.

Für eine erste Produktversion bietet es sich an, zu überlegen, für welche Zielgruppe diese erstellt werden sollte. Eine gängige Praxis dafür ist die Verwendung sogenannter Persona.

Eine Persona ist ein fiktiver Benutzer des Produkts, der ein bestimmtes Bedürfnis und einen definierten Hintergrund hat. In der Tabelle finden Sie drei mögliche Persona als Beispiele, die in der beschriebenen StorymapStorymap eine Rolle spielen könnten. Für kreative Teams ist es oftmals hilfreich, sich mit einem bestimmten Anwendertyp etwas besser identifizieren zu können, um aus seiner Sicht das Problem bestmöglich zu lösen.

Im weiteren Verlauf fügen Sie, angepasst an die Zielgruppe, die Stories hinzu, die für eine erste Version in Frage kommen. Auf diese Art und Weise sind Sie nun in der Lage, eine Roadmap zu erstellen und verschiedene Produktveröffentlichungen zu planen. Wie eine solche User Story Map am Whiteboard aussehen könnte, sehen Sie in Abbildung 16.

Persona	Beschreibung	Bedürfnis	Kontext
Lisa	Lisa schläft gerne lange, frühstückt ausführlich und kümmert sich morgens um ihre beiden Katzen Bijou und Felix.	stressfreier Morgen, mit reichhaltigem Frühstück und Zeit für die Katzen	Lisa lebt mit ihrem Mann zusammen, der immer nach ihr das Haus verlässt.
Hans	Hans steht früh auf und frühstückt nie. Er liebt seine Arbeit und verbringt gerne seine Zeit dort.	schnell und gepflegt aus dem Haus zur Arbeit gelangen	Hans lebt allein und hat auch keine Haustiere. Er ist ein Karrieremensch.
Peter	Peter ist alleinerziehender Vater, der seine zwei Kinder morgens aufweckt und ihnen Frühstück macht. Er verlässt das Haus gemeinsam mit ihnen und setzt sie auf dem Weg zur Arbeit in der Schule ab.	glückliche Kinder	Peter hat die Verantwortung für seine beiden Kinder. Die Schule der beiden liegt auf seinem Arbeitsweg.

Tab. 5:

Beispiele für Persona

Abb. 16:

Darstellung einer User Story Map