E-Learning: User Stories

• beschreiben Anforderungen aus Sicht der Stakeholder, die das Produkt nutzen
• bilden schlüssige Einheiten, die für sich realisiert werden können
• bilden die Basis für die schrittweise Realisierung des Produkts

User Stories sollen in ihrer Darstellung der Kundenwünsche möglichst prägnant und eingängig sein. Wesensmerkmal einer Geschichte, der „Story“, ist es, dass es dort einen Spannungsbogen gibt. In jeder guten Geschichte gibt es einen Helden, der im Laufe der Geschichte eine Wandlung erfährt. In diesem Sinne sollten auch User Stories gute Geschichten sein. Schließlich will der Nutzer ja auch mit seinem Produkt etwas erreichen. Es gibt Vorlagen für die Struktur einer User Story, die typischerweise wie folgt aussehen:

Als X möchte ich Y damit Z.

Dabei ist 

• X ein bestimmter Benutzer, eine Rolle oder eine Benutzergruppe, 
• Y beschreibt, was gemacht werden soll, und 
• Z gibt das Ziel an, das damit erreicht werden soll.

Beispiel: Für ein Abrechnungssystem könnte eine User Story so lauten:

„Als Mitarbeiter der Buchhaltung möchte ich alle offenen Rechnungen angezeigt bekommen, damit ich sehen kann, welche Rechnungen seit Längerem nicht bezahlt wurden.“

Insbesondere die Angabe des Ziels ist eine Stärke bei den User Stories. In vielen Projekten, bei denen mit anderen Formen der Anforderungsbeschreibung gearbeitet wird, bleibt das Ziel von Anforderungen für die Entwicklung unklar. Und genau dies ist eine der fatalsten Wissenslücken, auf der viele Missverständnisse und spätere Programmfehler basieren. 

Die 5Why-Technik

Bei der Sammlung von User Stories lohnt es sich, das Ziel ganz genau zu hinterfragen. Hierzu kann auch die sogenannte 5Why-Technik aus dem Managementsystem SixSigma hilfreich sein. Dabei hinterfragt man ein Ziel (in SixSigma ursprünglich ein Problem) mehrfach mit „Wozu möchtest du das?“. Es ist erstaunlich, wie sich das Verständnis für die Ziele und Prozesse der Kunden in der Praxis dadurch erhöhen kann. Übertragen auf das Beispiel oben, könnten die Fragen und Antworten wie folgt aussehen:

• Frage: Wozu möchtest du die offenen Rechnungen sehen?
• Antwort: Damit ich herausfinden kann, wer seine Rechnungen öfters nicht bezahlt.
• Frage: Wozu möchtest du herausfinden, wer seine Rechnungen öfters nicht bezahlt?
• Antwort: Damit ich diese Personen in eine Warnliste aufnehmen kann.
• Frage: Wozu möchtest du diese Personen in eine Warnliste aufnehmen?
• Antwort: Damit diese Personen einen niedrigeren maximalen Bestellwert bekommen.
• …

Bisweilen erarbeitet man sich durch solche Zielbeleuchtungen auch ein genaueres Verständnis dazu, wie das Produkt kundenfreundlicher gestaltet werden kann. Im Beispiel oben wäre sicher eine Sortierung nach den Rechnungsempfängern eine hilfreiche Funktion. 

Es scheint zwar so, aber oft ist es gar nicht so einfach, den Nutzen einer Story zu beschreiben, ohne dabei die Lösung einzuschränken. Was damit gemeint ist, lässt sich an einem einfachen Beispiel aus dem Hausbau verdeutlichen. 

Beispiel: Ein Bauherr hat bei seinem Architekten als Wunsch für einen Raum „große Fenster“ angegeben. Nach dem Hinterfragen des Wunsches kommt heraus, dass sein eigentliches Ziel darin besteht, bei Tageslicht lesen zu können. Dieses Ziel ließe sich vielleicht mit anderen Lösungen wie z. B. einer neuen Raumaufteilung besser oder kostengünstiger erreichen. Die voreilige Einschränkung der Lösung auf „große Fenster“ könnte also unnötig hohe Kosten verursachen.

Eine gute Geschichte veranlasst uns, mit dem Helden mitzufühlen. Genauso sollten User Stories es den Produktentwicklern ermöglichen, sich in die Bedürfnisse der Anwender des Produktes hineinzudenken.

Akzeptanzkriterien

Um das Verständnis zu erhöhen und die Testbarkeit sicherzustellen, werden User Stories im Allgemeinen mit Akzeptanzkriterien versehen. Dabei handelt es sich um kurze, einfach zu testende Zielbeschreibungen, die den Produktentwicklern helfen, die User Story genauer zu begreifen. 

Beispiel User Story:
„Als Mitarbeiter der Buchhaltung möchte ich mir alle offenen Rechnungen anzeigen lassen, damit ich sehen kann, welche Rechnungen seit Längerem nicht bezahlt wurden.“

Hierfür könnten folgende Akzeptanzkriterien festgelegt werden:

• Für jede Rechnung werden die Rechnungsnummer, der Kundenname, die Kundennummer, das Rechnungsdatum und das Saldo angezeigt.
• Es kann ausgewählt werden, wie viele Rechnungen pro Seite angezeigt werden.
• Es wird angezeigt, wie viele Rechnungen insgesamt gefunden wurden.

Die Akzeptanzkriterien präzisieren die User Story in den Anforderungen. Üblicherweise werden diese Kriterien nicht gleich zu Beginn eines Projektes festgelegt, sondern erst, bevor eine User Story in die Entwicklung kommt. Dadurch lässt sich unnötige Arbeit für diejenigen User Stories vermeiden, die sich im Laufe der agilen Entwicklung ändern oder sogar ganz wegfallen. 

Kriterien für gute User Stories: INVEST

Das Entwickeln guter User Stories ist in der Praxis nicht so einfach, wie es in der Theorie auf den ersten Blick scheint. Zur Orientierung, was eine gute User Story ausmacht, hat sich das Akronym INVEST bewährt. Es stammt von Bill Wake, der es speziell für User Stories entwickelt hat.

Die einzelnen Buchstaben stehen für:

• I– Independent (Unabhängig): Die verschiedenen User Stories sollten unabhängig voneinander sein, damit sie die Entwicklung in der Reihenfolge ihrer Bearbeitung nicht einschränken. Die Reihenfolge, in der sie bearbeitet werden, sollte ja weitgehend dem Kundennutzen folgen.
• N– Negotiable (Verhandelbar): Negotiable steht dafür, dass der Inhalt der User Stories nicht von Anfang an genau feststeht, sondern während der Entwicklung vom Kunden nachgeschärft werden kann. Allerdings sollte dies nur geschehen, solange die User Story noch nicht in der aktuellen Iteration, also bereits in der konkreten Umsetzung ist.
• V– Valuable (Nützlich): Da die User Stories aus Sicht des Kunden geschrieben sind, sollten sie für diesen auch Wert haben und im Produkt einen konkreten Nutzen für ihn stiften. Eine User Story sollte also insbesondere nicht einen technischen Aspekt des Produktes beschreiben, der für den Kunden unverständlich ist.
• E– Estimable (Quantifizierbar): Damit eine User Story in eine Iteration eingeplant werden kann, muss ihr Aufwand abgeschätzt werden können. Manchmal müssen User Stories erst weiter zerlegt oder mit Akzeptanzkriterien genauer beschrieben werden, bevor sie vernünftig geschätzt werden können. 
• S– Small (Klein): Der Umsetzungsaufwand für eine User Story sollte nur so groß sein, dass mehrere User Stories in eine Iteration passen. In vielen Projekten haben User Stories eine typische Größe von ein bis zwei Wochen. Ziehen sie einen längeren Umsetzungsaufwand nach sich, so z. B. mehrere Monate, handelt es sich eher um Epics, die noch in User Stories heruntergebrochen werden müssen. 
• T– Testable (Überprüfbar): Damit die Produktentwickler eine klare Aussage treffen können, ob eine User Story fertig umgesetzt ist, sind Testfälle sehr hilfreich. Im Allgemeinen lassen sich auch aus den Akzeptanzkriterien sinnvolle Testfälle ableiten.