User Story Training
by Frank Schatz

User Stories – Anwendergeschichten für agile Teams

Inhalt

User Stories (Anwendergeschichten) erzählen Arbeitsabläufe in der Zukunft, aus der Sicht des Benutzers. In der Regel bestehen User Stories aus einem Satz und einigen Akzeptanzkriterien. Aus Sicht eines Autors kann man User Stories auch als Plot bezeichnen – den Handlungsrahmen. Die Geschichte wird von den Developern in Scrum Teams gemeinsam mit dem Product Owner zu Ende geschrieben.

In diesem Artikel erfährst du, wie eine gute User Story aufgebaut ist und wie du User Stories bei der Produkt-Entwicklung erfolgreich einsetzt.

Herkunft der User Stories

User Stories beschreiben in der Softwareentwicklung Features in natürlicher Sprache. User Stories wurden 1995 das erste Mal von Ward Cunningham beschrieben und 1999 von Kent Beck in seinem Buch “Extreme Programming Explained” verwendet.

Entgegen der fälschlichen Annahme, dass User Stories Bestandteil von Scrum sind, werden User Stories bei verschiedenen Frameworks und Prozessen wie zum Beispiel SAFe® und Kanban verwendet.

Aufbau von User Stories im Detail

User Story Card

Es gibt kein allgemein gültiges Format, für die Beschreibung von User Stories. Trotzdem entwickelte Rachel Davies bei der englischen Firma Connextra in den frühen 2000er Jahren ein einfaches Template für User Stories. Dieses Template ist nicht nur leicht anzuwenden, sondern das wohl auch bekannteste Format für die Beschreibung von User Stories:

Als [ROLLE] möchte ich [FEATURE] damit [NUTZEN]

Dieses Template wird noch heute gerne beim Einstieg in die Produkt-Entwicklung mit User Stories verwendet. Fortgeschrittene verwenden gerne WER, WAS und WARUM.

Diese drei einfachen Elemente des User Story Templates erklären:

  • Wer oder welche ROLLE fordert an
  • Was für ein FEATURE ist gefordert
  • Welchen NUTZEN das Feature bietet

Betrachten wir diese drei Kernelemente des User Story Template im Detail:

ROLLE: Wer fordert an?

Eine Rolle wird von einer Person, mit einem definierten Handlungsauftrag betraut ist. Eine Person kann beliebig viele Rollen annehmen und eine Rolle kann von beliebig vielen Personen gespielt werden.

Zum Beispiel können die Rollen Fußballspieler und die Rolle Zeugwart Anforderungen an einen Sportschuh haben. Der eine benötigt vielleicht ein besonderes Verschlusssystem, der andere leicht zu reinigendes Obermaterial.

Wenn eine von der Rolle Zeugwart in die Rolle Fußballspieler wechselt, wechseln auch seine Anforderungen an einen Fußballschuh. Eine User Story ist deshalb immer aus dem Betrachtungswinkel einer speziellen Rolle geschrieben.

Es ist sinnvoll, mit Stellvertretern (Proxy) der Rolle zu arbeiten, wenn diese nicht persönlich zur Verfügung stehen. Für diese Stellvertreter werden in der Regel Personas definiert.

Bei Systemen, die autonome Vorgänge durchführen, können andere Systeme Anforderer sein und eine Rolle spielen.

FEATURE: Was wird gefordert?

Der zweite Teil des Templates beschreibt die geforderte Funktionalität. Hier beschreibt der Benutzer das gewünschte Ergebnis, nach dem die Handlung durchlaufen ist.

Der Benutzer möchte keine Funktionalität, sondern das Resultat nach Ablauf der Handlung.

Ein Beispiel: Als Fahrzeugführer, möchte ich ein Signal auslösen, um andere Verkehrsteilnehmer zu warnen.

In kürzerer Form sieht das so aus:

Wer: Fahrzeugführer

Was: Signalton auslösen

Warum: Verkehrsteilnehmer warnen

Dabei ist es dem Benutzer – in unserem Fall in der Rolle Fahrzeugführer, egal wie das Signal zustande kommt. Dies zu lösen ist Sache der Entwickler. Allerdings wird der Benutzer in den Gesprächen noch Einfluss darauf nehmen, dass der Auslöser für das Signal, gut von der Fahrerposition aus zu erreichen ist.

NUTZEN: Welchen Nutzen bietet das Feature?

Bleiben wir bei dem Beispiel des Fahrzeugführers.

Das Realisieren von Features verursacht Kosten. Wer die Rechnung bezahlt ist auch daran interessiert zu erfahren, ob die Kosten einen adäquaten Nutzen bieten. Das ist der sogenannte Return on Invest (ROI).

Selten lässt sich in der agilen Softwareentwicklung der ROI eines Features direkt berechnen. Dann wird auf Annahmen zurückgegriffen. Weil in der Praxis die Entwickler nicht mit Geldbeträgen hantieren, greifen die Stakeholder auf Business Values zurück, um den Wert abzubilden.

Im Falle des Warnsignals ist der ROI sicherlich hoch, weil die Vermeidung von Unfällen, Sach- und Personenschäden wirtschaftlich eine lohnenswerte Sache sind.

Hast du bei dem Warnsignal an eine Hupe gedacht? Sei vorsichtig mit solchen Annahmen, wenn du den Kontext nicht kennst!

Bei einem Kraftfahrer ist Hupe wohl zutreffend, es könnte aber auch die Warnblinkanlage sein oder die Lichthupe. Wenn der Kontext aber einen Piloten oder Kapitän betrifft, sieht das Feature völlig anders aus.

In den erforderlichen Gesprächen zwischen Stakeholdern, Benutzern und Entwicklern werden sich diese Fragen klären, wenn sie sich nicht über die Akzeptanzkriterien der User Story beantworten lassen.

Akzeptanzkriterien in User Stories

Damit sich überprüfen lässt, ob ein Feature wie gewünscht realisiert wurde, wird eine User Story mit messbaren Werten angereichert. Messbar deshalb, weil die Akzeptanzkriterien die Basis für den Abnahmetest darstellen.

Akzeptanzkriterien sollen dem Akronym S.M.A.R.T genügen. Die einzelnen Buchstaben bedeuten: spezifisch, messbar, attraktiv, realistisch und terminiert.

Weil ein Benutzer nicht immer alle Aspekte seiner Anforderung betrachtet, liegt es auch beim Entwicklungsteam, durch strukturierte Fragen die Akzeptanzkriterien in eine vollständige und valide Form zu bringen.

Achte darauf, dass du über die Akzeptanzkriterien keine neuen Features einführst!

Vorsicht vor elektronischen Tools

Bei Verwaltungstools wie zum Beispiel dem Jira von Atlassian, ist es möglich buchstäblich unendlich viel Text zu User Stories zu erfassen. Das verführt gerade unerfahrene agile Personen, diesen Platz füllen zu wollen. In der Folge werden zu viele Details beschrieben. Dadurch wird die User Story für Entwickler „Fertig“ aussehen und die gewünschte Diskussion unterbleibt.

Folge dem einfachen Rat von Mary Poppendieck: Wenn deine Story nicht auf die Karte passt, nimm eine kleinere Karte!

Mary Poppendieck ist Autorin mehrerer Bücher. Unter anderem schrieb sie das Buch: Lean Software Development – An agile Toolkit.

Das bedeutet: Fasse dich kurz. Besser etwas kürzer!

Vor dem Backlog kommt die User Story Map

User Stories werden in einem Product Backlog verwaltet. In Scrum verantwortet der Product Owner den Inhalt und die Priorisierung. Die wichtigsten Kriterien um eine User Story im Product Backlog zu priorisieren sind der Business-Value, die Komplexität in Story Points und ob der Outcome der User Story zum Sprint Ziel passt.

User Story Map
User Story Map

Das Product Backlog ist eindimensional

Ein Product Backlog ist eine gewöhnliche Liste von allen Aufgaben, die erledigt werden müssen, um das Produkt fertig zu stellen. Listen beschränken sich auf eine vertikale Dimension und können das Gesamtprodukt nicht für Menschen verständlich im Zusammenhang zeigen.

Jeff Patton kam auf die Idee, dem Product Backlog eine horizontale zweite Dimension hinzuzufügen. So blieb die Priorisierung erhalten und die Zusammenhänge und Abläufe können auf der horizontalen Achse sequentiell dargestellt werden. Diese zweite Dimension schafft es, dem Betrachter ein Gesamtbild des zu entwickelnden Produkts zu vermitteln.

Die Vorgehensweise, um eine User Story Map zu erstellen, beschreibt Jeff Patton in seinem Buch: “User Story Mapping, die Technik für besseres Nutzerverständnis in der agilen Produktentwicklung”.

Abweichungen vom Happy Path, mit User Stories modellieren

Mit User Story Mapping hast du  einen entscheidenden Vorteil. Mit ihnen lassen sich Szenarien wie Ausnahmen, Fehlerfälle, Alternativen abzubilden. So können nach dem Modellieren eines Szenarios, die relevanten User Stories in ein Product Backlog überführt werden.

Release mit User Stories planen

In einem Product Backlog kannst du Stories zu Sprints gruppieren, jedoch kannst du mit einem Product Backlog keine Releases planen. Mit User Story Maps ist das Planen von Releases einfach. Ziehe einfach eine horizontale Linie unter die User Stories. Das ist der sogenannte Slice. Dann ziehst du die im Release nicht benötigten User Stories unter diese Linie. Fertig.

Wichtige Artefakte bei der Verwendung von User Stories

Um Diskussionen und Missverständnisse beim Schreiben von User Stories zu vermeiden, brauchst du eine Vereinbarung mit den direkt an der Produkt-Entwicklung Beteiligten. Unabhängig davon, ob du Scrum, Kanban, SAFe® oder andere agilen Techniken anwendest. Mit den folgenden Artefakten wird vieles leichter:

Die Definition of Ready

Bei der Arbeit mit User Stories wirst du feststellen, dass die Frage aufkommt, ob eine User Story bereit für die Umsetzung ist. Hier kommt die Definition of Ready (DoR) ins Spiel.

Die DoR ist eine Liste von Prüfungen, um formal festzustellen, dass eine User Story weit genug ausgearbeitet und verstanden ist. Denn erst, wenn eine User Story diesen Reifegrad erreicht hat, ist sie in die Umsetzung zu geben.

Entwicklungsteams, die keine DoR definieren, verirren sich regelmäßig in Verständnisfragen.

Die Definition of Done

Damit du feststellen kannst, ob eine User Story Done – im Sinne von fertig ist, musst du verstehen, was „Done“ bedeutet.

Die Definition of Done (DoD) ist eine Vereinbarung der Produktentwickler und darin wird definiert, was alles geprüft werden muss, um eine User Story als fertig zu klassifizieren. Fertig oder Done bedeutet, dass absolut nichts mehr an der User Story getan werden muss.

Die DoD beinhaltet eine Checkliste von Prüfungen, die mit positivem Ergebnis durchgeführt werden müssen, um die User Story als Done zu bezeichnen.

Die Definition of Done ist ein lebendiges Artefakt. Jederzeit können neue Erkenntnisse Änderungen notwendig machen.

Mein Fazit

User Stories sind für die Produkt-Entwicklung ein wertvolles Instrument, um bessere Produkte zu erschaffen. Durch ein standardisiertes Template, scheint es als wären User Stories leicht zu handhaben. Das ist ein gefährlicher Trugschluss. Nur durch tiefgreifendes Wissen um die Arbeit mit User Stories werden Entwicklungsteams aus unterschiedlichsten Branchen erfolgreich sein. Unternehmen und Mitarbeiter sind gut beraten, gezielt in die Qualifizierung für die Arbeit mit User Stories zu investieren.

Bleib Gesund!

Frank Schatz,
damit es agil wird.

Share on facebook
teilen
Share on twitter
twittern
Share on pinterest
pinnen
Share on linkedin
LinkedIn
Share on xing
xingen
Frank Schatz

Frank Schatz

ist geprüfter Sachverständiger für agiles Projektmanagement, agiler Trainer, zertifizierter Scrum Master und Certified Instructor. Frank fokussiert sich auf die Reparatur agiler Projekte und dem Schreiben besserer User Stories.
Sein Motto: Menschen größer werden lassen.

User Story Zertifizierung

Certified User Story Professional

Beschleunige deine Karriere und erschaffe bessere Produkte.