ScrumSo erstellen Sie gute User Storys
User Storys sind das wichtigste Werkzeug, um agile Projekte inhaltlich zu steuern. Mit User Storys werden die Anforderungen der Kunden an ein Softwareprodukt oder an eine Geschäftslösung beschrieben. Die Entwickler erfahren durch eine User Story, was genau der Auftraggeber oder Nutzer will und warum er das will.
Was sind User Storys?
User Storys sind Nutzergeschichten und Grundlage für ein Scrum-Projekt. Der Product Owner beschreibt in einer User Story die Anforderungen aus Nutzersicht: Wie wünschen sich Anwender eine Software oder Kunden einen Liefergegenstand, um ihre Geschäftsziele zu erreichen.
Obwohl der Begriff „User Story“ im Scrum Guide nicht auftaucht, nutzen agile Arbeitstechniken ihn häufig. User Storys stehen im Backlog neben Epics und Tasks, Qualitätsanforderungen, Fehlern und Verbesserungen. Eine User Story besteht aus wenigen, leicht verständlichen Sätzen. Sie sind kurz, aus Kundensicht jedoch spezifisch und detailliert.
User Storys transportieren nicht nur Erwartungen an zukünftige IT-Systeme, sondern auch Anforderungen an Liefergegenstände, die agile Projekte realisieren. User Storys bewegen sich im Anforderungsraum, ohne in den Lösungsraum zu wechseln. Sie geben keine technischen Lösungen vor, die die Entwickler zum sturen Realisieren zwingen.
Beispiele für User Storys
Folgende User Storys zeigen, worum es jeweils gehen kann und wie einfach eine User Story im ersten Schritt formuliert sein kann:
- Ein neuer Kunde soll sich bei einem E-Learning-Portal registrieren, um sich auf eine Zertifizierung vorzubereiten.
- Ein Kunde möchte Waren in einem Webshop auswählen und dann bestellen.
- Ein IT-Administrator möchte Datenbanken verwalten, indem er Datensätze anlegt, ändert oder löscht.
- Eine Abteilung in einem internationalen Konzern soll in einen neuen Bereich und damit in eine neue Struktur überführt werden.
Epic, Story und Task
Die folgende Grafik illustriert den Zusammenhang zwischen Epics, Storys und Tasks als Elemente eines Scrum-Projekts.
Epic
Epic ist eine User Story auf höchster Abstraktionsstufe. Für einen Sprint ist sie zu groß. Der Product Owner zerlegt sie deshalb in mehrere kleinere User Storys.
Story
Die Story ist eine User Story und Teil einer Epic. Eine Story enthält die Anforderungen, geschrieben als kleine handhabbare Texte. Auf dieser Basis schätzt das Scrum-Team den Aufwand für die Realisierung der Anforderung ein.
Task
Entwickler und Tester zerlegen eine Story in einzelne Aufgaben (Tasks). Wenn eine Aufgabe eine vereinbarte Zeitspanne überschreitet, kann sie in zusätzliche Aufgaben aufgeteilt werden. Eine Story ist dann erledigt, wenn alle Aufgaben der Story erledigt sind.
Wie sollte eine User Story formuliert sein?
Eine User Story sollte einfach und leicht verständlich sein. Das gelingt mit einfachen Satzkonstruktionen: Subjekt, Verb, Objekt. Mehrdeutige Begriffe gehören nicht in eine User Story.
Die User Story soll sich auch auf das Wesentliche konzentrieren. Rachel Davie, Co-Autorin des Buchs „Agile Coaching“, empfiehlt die Formulierung der User Story nach folgendem Muster:
„Als [Rolle] möchte ich [Funktion] um [Nutzen].“
Dabei ergeben sich Rolle, Funktion und Nutzen aus den Antworten auf die folgenden W-Fragen:
Wer fordert etwas an? (=Rolle)
Der Anforderer ist meist der spätere Nutzer des Systems oder der Nutznießer der zu entwickelnden Lösung.
Was wünscht sich der Anforderer? (=Funktion)
Der Anforderer wünscht sich, dass etwas Bestimmtes passiert. Je klarer und präziser der Wunsch in die User Story eingeht, desto hilfreicher ist die User Story für das Entwicklerteam, um die Anforderungen zu realisieren.
Warum ist das für den Geschäftsfall wichtig? (=Nutzen)
Durch die Anforderung soll ein Ziel erreicht werden. Der Anforderer verspricht sich davon einen Nutzen. Die Beschreibung des Grundes der Anforderung liefert dem Entwicklerteam weitere Informationen zur richtigen Ausführung.
Beispiele für die Formulierung einer User Story
Ein Beispiel für dieses Schema einer User Story ist: Ein E-Learning-Portal, das Seminare für Projektleiter anbietet, könnte für die Registrierung eines neuen Kunden diese User Story texten:
Als Neukunde möchte ich mich im E-Learning Portal registrieren, um mich auf die PMI-Zertifizierung vorzubereiten.
Ein weiteres Beispiel ist:
Als Mitarbeiterin möchte ich auf meiner Startseite des Intranets eine Liste der von mir am häufigsten genutzten Seiten haben, um schnell und direkt auf die Informationen zugreifen zu können.
Was ist eine gute User Story?
Mit den INVEST-Kriterien erkennt der Product Owner, ob die User Story gut ist.
Independent (unabhängig)
Jede einzelne Geschichte sollte unabhängig von anderen User Storys sein. Die Umsetzung einer Story darf nicht voraussetzen, dass vorher eine andere Story umgesetzt wurde.
Negotiable (verhandelbar)
User Storys sind keine unumstößlichen Vertragstexte. Product Owner, Stakeholder und das Entwicklerteam diskutieren und präzisieren eine User Story gemeinsam, um ein optimales Verständnis zu erzielen.
Valuable (nützlich)
Das Ergebnis der Story muss für den Anwender sinnvoll sein und Wert stiften.
Estimable (schätzbar)
Das Entwicklerteam muss in der Lage sein, Aufwände für die Realisierung abschätzen zu können.
Small (klein)
Der Umfang der User Story sollte angemessen sein, das heißt, sie sollte in einem Sprint realisierbar sein.
Testable (testbar)
Jede User Story muss getestet werden können. Mit dem Test wird die erfolgreiche Umsetzung der User Story festgestellt.
Was ist eine Story Card?
Es bleibt dem Product Owner überlassen, wie er User Storys erfasst und verwaltet. Der Scrum Guide schreibt ihm nichts vor. In der Praxis hat es sich jedoch als sinnvoll erwiesen, die User Story auf eine Story Card zu notieren. Auf der Story Card wird die Anforderung des Users nach dem oben beschriebenen Satzschema und nach den INVEST-Kriterien formuliert.
Zudem können weitere Informationen ergänzt werden, die Entwicklern bei der Planung und Umsetzung mit Scrum helfen: zum Beispiel Bezug zur Epic oder ein Name für den User oder ein Datum. Damit haben Entwickler auf einer Seite (Karte) einen Überblick, was gefordert ist (siehe folgende Abbildung).
Card, Conversation, Confirmation
Neben den INVEST-Kriterien gibt es noch andere Regeln bei der Erstellung von User Storys. Ron Jeffries nennt drei kritische Aspekte, die beim Erstellen von User Storys beachtet werden sollten: Card, Conversation und Confirmation.
Card
Geschichten werden traditionell auf Karten geschrieben. Deshalb sollten sich Product Owner kurzfassen und nicht mehr Platz verbrauchen als die Karte es zulässt.
Conversation
Anforderungen sollten dem Entwicklerteam nicht „über den Zaun“ geworfen werden. Auftraggeber und Entwickler sollten miteinander über die Karten sprechen, um so das Verständnis aller Beteiligten zu schärfen. Denn der Teufel steckt im Detail. Erst im Gespräch zeigt sich, ob den Entwicklern wirklich klar ist, was sie realisieren sollen.
Confirmation
Eine User Story ist dann abgeschlossen, wenn die Akzeptanzkriterien erfüllt sind. Sie beschreiben, was von der Story erwartet wird, um sie als „fertig“ (done) zu melden. Akzeptanzkriterien sind flexibel und werden bei Bedarf angepasst, bis das Team mit der Realisierung der User Story startet. Scrum Master und Entwicklerteam klären in Gesprächen, ob ein gemeinsames Verständnis besteht. So werden Missverständnisse vermieden, die im Nachgang zeitfressend ausgeräumt werden müssten.
Was tun, wenn die User Story zu groß ist?
Sind User Storys zu umfangreich, kann das Team den Aufwand kaum verlässlich abschätzen. Deshalb spaltet der Product Owner die Anforderungen in kleinere Einheiten. Wie geht er dabei am besten vor, ohne wertvolle Informationen zu verlieren?
User Story vertikal formulieren
User Storys sollten vertikal formuliert werden. Das heißt: Unterschiedliche Bereiche eines technischen Systems, wie zum Beispiel Frontend und Backend, adressieren. Am Ende eines Sprints sollte dem Kunden eine Funktionalität zur Verfügung stehen, die vollständig nutzbar ist.
INVEST-Ansatz beachten
Prüfen, ob die User Storys dem INVEST-Ansatz entsprechen.
Sich auf den größten Nutzen konzentrieren
Besitzt die Anforderung einen simplen Kern? Verspricht dieser den größten Nutzen für den Geschäftsablauf? Nach Geschäftsfällen ordnen und sich auf die mit dem größten Nutzen fokussieren.
Komplexität verringern
Optionen und Komplexität sollten verringert werden. Wenn der Anwender zum Beispiel keine komplexe Oberfläche benötigt, ist es vielleicht möglich, mit einem schlichten und einfachen Design zu starten.
User Story aufsplitten
Umfangreiche User Storys sollten nach Funktionen, Aktionen oder Operationen aufgesplittet werden, die der Benutzer separat ausführen kann.
