Eine User Story lässt sich relativ einfach definieren. Sie beschreibt anhand einer Story ein ganz bestimmtes Bedürfnis eines Anwenders (= User). Und das in einer einfach verfassten Sprache (im Idealfall in der des Kunden und ohne Verwendung von Fachbegriffen).
Sie besteht aus einer aussagekräftigen Überschrift und ist kurz gehalten (ca. ein bis zwei Sätze lang) und zielorientiert. Im Gegensatz zu Use Cases (= Anwendungsfall) sind sie nicht so detailliert und legen den Fokus mehr auf das, was wirklich wichtig ist. Viele Mitarbeiter in agilen Teams sind zwischenzeitlich der Auffassung, dass User Stories besser für eine Zusammenarbeit im Team geeignet sind, als die sogenannten Use Cases.
9 Kriterien, die eine User Story ausmachen
- Bei einer User Story handelt es sich nicht um eine Aneinanderreihung von Aktionen. Sie beschreibt aus der Sicht des Users (Rolle -> Ziel) kurz und verständlich die Funktionalität.
- Die User Story ist kurz gehalten und besteht aus ein oder zwei Sätzen (Rolle -> Ziel). Deren Inhalt wird dann im Team diskutiert um sicher zu stellen, dass jeder das Gleiche versteht.
- User Stories können als Teil von Use Cases gesehen werden.
- User Stories werden bevorzugt für die Planung von Projekten eingesetzt.
- User Stories lassen sich schneller schreiben und benötigen nicht so viel Zeit für die Analyse und das Schreiben, wie Use Cases.
- User Stories basieren auf verbaler Kommunikation, Diskussion und Zusammenarbeit innerhalb des Teams.
- User Stories müssen in einer Iteration implementiert und getestet werden, im Gegensatz zu Use Cases.
- User Stories können von jedem geschrieben werden (Benutzer oder Kunden, Product Owner, Entwickler etc.).
- User Stories beinhalten Akzeptanzkriterien / Akzeptanztests. Diese stehen in der Regel bei der Verwendung von User Story Karten auf der Rückseite. Sind es mehr als 10 Akzeptanzkriterien, ist das ein Zeichen dafür, dass eine User Story zu groß geraten ist.
Definition: In Scrum wird eine Iteration als Sprint bezeichnet. Es handelt sich hierbei um einen festgelegten Zeitrahmen von ein, zwei bis vier Wochen in denen agile Teams ein auslieferbares Produkt entwickeln.
User Story Kriterien nach dem INVEST Prinzip
Independent (I) Sie ist nicht von einer anderen User Story abhängig
Negotiable (N) Sie dient als Gesprächsgrundlage und kann gemeinsam weierentwickelt werden.
Valuable (V) Sie stellt immer einen Vortail für den User, Kunden oder Auftraggeber dar.
Estimatable (E) Sie ist schätzbar. Sie hat also soviel konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann.
Small (S) Sie hat die richtige Größe.
Testable (T) Sie kann getestet werden.
Beispiel einer User Story
Ein kurzes Beispiel für eine etwas ausführlichere User Story könnte so aussehen:
```Überschrift: Anzeige Datenschutzerklärung bei Systemanmeldung Story: Jeder angemeldete Anwender muss vor der Verwendung personenbezogener Daten bestätigen, dass er die Datenschutzerklärung gemäß den rechtlichen Anforderungen beachtet. Akzeptanzkriterien:
- Textinformation wird bei jeder Systemanmeldung angezeigt und muss bestätigt werden.
- Bestätigt der Anwender die Datenschutzerklärung nicht, wird er nicht am System angemeldet.
- Die Datenschutzerklärung muss durch beauftragte Personen (Rollen) inhaltlich gepflegt werden können. ```
Damit das Projektteam innerhalb des geplanten Sprints diese umsetzen kann, ist es notwendig, dass die User Story im Product Backlog schon einige relevante Punkte bis zum ersten Sprint Planning enthält: 
- eine Überschrift
- die User Story, also Beschreibung, welche die Basis für die weitere Konversation zwischen dem Produkt Owner und dem (Entwickler-) Team liefert. Diese Diskussion endet idealerweise mit einem klaren Statement für die Akzeptanzkriterien.
- Akzeptanzkriterien (Kriterien, woran wir erkennen, dass die Story die Funktionalität enthält, die gewünscht ist)
- eine zeitliche Abschätzung (z.B. mittels Story points)
- bei Bedarf z.B. noch Testfälle, oder was nicht den Anforderungen entspricht, Wire Frames, UI-Design etc.
Im Bezug auf User Stories werden die sogenannten Akzeptanztests (90% davon sollten automatisiert sein) auch oft Akzeptanzkriterien, Storytests, Testbestätigung, Zufriedenheitsfaktoren etc. bezeichnet. Sie sind notwendig um festzulegen, wann eine User Story als akzeptiert gilt.
Wer User Stories schreibt und wann
User Stories können von jedem im Team geschrieben werden, nicht nur vom Product Owner (PO). In der Regel finden für alle Teammitglieder vor Projektbeginn sogenannte User Story Workshops statt, welche eine Einführung in das richtige Schreiben von User Stories liefern. Ziel ist es, ein Produkt Backlog zu generieren, welches die Funktionalität eines kompletten Projekts beschreibt, oder zumindest die geplante Funktionalität für den kommenden 3 bis 6 monatigen Release-Zyklus. Geschrieben werden die User Stories während der gesamten, agilen Projektdurchführung und werden dann im Produkt Backlog abgelegt, wo sie vom Product Owner priorisiert werden können.
User Stories priorisieren Der Product Owner überlegt als erstes, welche User Stories aus dem Backlog am wichtigsten sind, damit die Anwendung minimal läuft. Must Have Stories Aus den vorhandenen User Stories identifiziert es deshalb sogenannte “Must Have” User Stories, ohne die das System nicht gehen würde. Und welche die Voraussetzung für die anderen Stories sind, damit diese dem Kunden bzw. User einen Mehrwert (Value) bieten.
User Stories werden nach Must Have und Should Have priorisiert.
Should Have Stories Anschließend kümmert er sich um die “Should Have” User Stories. Die sind unbedingt nötig, damit der Kundenmehrwert sicher gestellt ist und somit umgesetzt werden müssen. Somit wird eine User Story mit geringer Wichtigkeit höher priorisiert, wenn eine andere wichtigere User Story von dieser abhängt.
Stories im Team diskutieren Das Team diskutiert und analysiert dann gemeinsam die User Stories und entscheidet, welche davon im kommenden Sprint umgesetzt werden.
Gute User Story schreiben
Um etwas mehr ins Detail einer User Story zu gehen erfahrt ihr in diesem Abschnitt, wie man eine wirklich gute User Story schreibt.
Aus Anwendersicht: Schreib die Story aus der User Perspektive und Benutzerrolle (z. B. Businessanwender, Konsument, Administrator, Redakteur etc.). Das typische Story-Format lautet meist: “Als (Benutzerrolle), möchte ich (Funktionalität), damit ich (Ziel) erreichen kann.”
Teamwork ist gefragt: User Stories schreiben ist Teamarbeit. Der Product Owner schreibt in der Regel zusammen mit dem Team die Story-Details für das nächste Sprint Planning Meeting, nachdem in einer gemeinsamen Diskussion die nötigen Details zum Verständnis der Story erarbeitet wurden.
Kommunikation ist wichtig: Damit die User Stories von allen Beteiligten richtig verstanden werden, ist es wichtig, dass sich das Team darüber ausdiskutiert, Ideen einbringt und versteht, worum es dem User geht. Eine User Story ist keine Spezifikation und sie ersetzt auch keinen Dialog untereinander.
Keep it simple: User Stories sind einfach und präzise. Sie sind in einer Sprache geschrieben, die jeder versteht. Komplexe und zweideutige Begriffe sollen vermieden werden. Man schreibt im Aktiv, nicht im Passiv und fokussiert sich auf die wichtigen Informationen.
Akzeptanzkriterien sind wichtig: Sogenannte Akzeptanzkriterien sind wichtig und müssen immer enthalten sein. Sie legen fest, wann eine Story komplett ist und stellen sicher, dass diese auch getestet werden kann.
Mit Papierkarten arbeiten: User Stories sollten sichtbar angebracht werden. Mit Hilfe von Papierkarten ist dies einfach möglich. Das Team hat etwas in der Hand und kann sich darüber oft besser Gedanken zur Story machen.
Immer im Blick behalten: Die User Stories sollten für jeden sichtbar sein. Es bringt nichts, wenn man sie schreibt und dann im Ticketsystem oder Intranet-Dschungel versengt. Es gibt Story-Boards, wo man die User Stories in Form von Papierkarten anbringen kann. So ist es möglich diese jedem visuell zu präsentieren, dadurch Diskussionen anzuregen bzw. aufrecht zu erhalten oder zwischenzeitlich auftretende Fragen zu klären.
Wer, was und wann?
Wer aus dem Scrum Team hat was mit den User Stories zu tun und wann? Das klären wir kurz in diesem Abschnitt:
Product Owner Priorisiert User Stories, fügt welche hinzu oder entfernt andere, entscheidet, welche User Stories in nächsten Sprint angegangen werden, teilt User Stories und Epics auf, nimmt fertige und getestete User Stories ab.
ScrumMaster Kann nicht direkt an einer User Story etwas ändern. Er hilft jedoch den PO dabei Sprint Planning Meetings zu organisieren, dem Team dabei Stories zu implementieren und Impediments zu beseitigen und das Review Meeting vorzubereiten.
Stakeholder Kann nicht direkt an einer User Story etwas ändern. Allerdings definiert er den Wert, die Priorität und Requirements.
Team Übernimmt die Zeitschätzung zu einer User Story während der Iteration, unterteilt User Stories in Tasks, entwickelt User Stories, sorgt für die User Story Qualität während der Entwicklung, demonstriert dem PO die User Story.
Was, wenn User Stories zu groß sind
Es gibt agile Projekte, die dazu tendieren, dass sie einige sehr groß geratene User Stories (sogenannte Epics) enthalten. Unter der Annahme, dass es nicht möglich ist, diese in kleine User Stories aufzuteilen.
Epics bringen generell immer Probleme mit sich. Deshalb diese, wenn möglich, vermeiden und lieber in kleinere User Stories aufteilen.
Definition von Epics Ein Epic ist eine User Story, die für sich allein zu groß für einen einzelnen Sprint ist. Der Terminus wird häufig verwendet, um eine sehr große User Story zu bezeichnen, die in kleinere Stories aufgeteilt werden muss. Epics machen nur dann Sinn, wenn sie für eine späte Zukunft geplant und nicht Teil des Release Planning sind.
User Stories, die zu groß geraten erzeugen auf Dauer Probleme. Das Team erinnert sich nicht lang genug an die Diskussionen und Akzeptanzkriterien zur User Story, die nötig sind, um die Story richtig zu implementieren. Es kommt zur Häufung von Bugs und falsch verstandenen Implementationsversuchen. In der Regel sollte eine User Story immer so klein ausfallen, dass sie von einem einzelnen oder mehreren Entwicklern (inklusive Tests und Akzeptanz) innerhalb von 2 bis 5 Tagen umgesetzt werden kann. Das hat zudem den Vorteil, dass man weniger Dokumentation hinsichtlich der User Story Details benötigt als, wenn eine User Story aufgrund ihrer Komplexität und daraus resultierenden Umsetzungsdauer ständig neu dokumentieren und aktualisieren werden muss.
Nachteile von sogenannten Epics
Viele Scrum Experten schlagen vor, dass Aufgaben, die mehr als 12 Stunden benötigen, um abgeschlossen zu werden, in kleinere Aufgaben aufgeteilt werden.
- Epics lassen sich schlecht schätzen. Sie enthalten zu viele unbekannte Faktoren, die etwas über die tatsächliche Größe aussagen.
- Sogenannte Epics, die eine Zeitschätzung enthalten, sind mit Vorsicht zu genießen. Sie verleiten den Product Owner zu einer falschen Einschätzung der Projektdauer.
- Ein Team, dass einen Epic schätzt, schätzt so eine User Story nie richtig ein, sondern veranstaltet eher ein Ratespiel. Es bindet sich durch diese Schätzung an eine Aufgabe, die aufgrund unbekannter Größenordnung niemals in der geschätzten Zeit abgeschlossen werden kann.
Möglichkeiten, große User Stories (Epics) aufzuteilen
- Aufteilen nach Workflows
- Aufteilen nach Business Use Cases
- Aufteilung nach Aufwänden (hoher Aufwand / geringer Aufwand)
- Aufteilung nach Komplexität
- Aufteilen nach Datenstruktur
- Aufteilung nach GUI Design
- Aufteilung nach Performance Varianten
- Aufteilen nach Grundfunktionalitäten
- Aufteilung nach Spikes (Recherchen)
Download: Das Story Splitting Cheat Sheet von Humanizing Work kann man sich als PDF in englischer Sprache hier downloaden.
Hinweis: Egal, wie eine Story aufgeteilt wird, um sie zu verkleinern. Es darf dabei nicht vergessen werden, dass am Ende immer noch eine Funktionalität für den User / Stakeholder vorhanden sein muss.
Fazit
Bei einer User Story geht es darum, wie ein Anwender eine Funktionalität versteht und das Team diese implementiert. Die beste Kommunikations-Möglichkeit dem Team klar zu machen, was der Anwender möchte, ist mit den Team-Mitgliedern darüber zu reden.
Um festzustellen, dass jeder aus dem Team die Diskussion zur User Story richtig verstanden hat, ist es wichtig Tests zu definieren. Es macht keinen Sinn sich nur auf die Dokumentation einer Aufgabe zu verlassen, weil diese oft nicht wirklich gelesen wird, noch vollständig oder aktuell ist. Wurde alles richtig gemacht und implementiert, sowie entsprechend getestet, wird die Aufgabe als akzeptiert abgenommen.
Es ist durchaus wichtig, dass User Stories nieder geschrieben werden. Aber eine dokumentierte User Story ist nicht der Hauptteil, sondern die dazugehörige Kommunikation mit dem Team und die Akzeptanztests. User Stories werden gerne in agilen Projekten eingesetzt, denn sie fördern die Zusammenarbeit des Teams und zeigen gleichzeitig den Wert einer Aufgabe aus der Kunden- bzw. Benutzerperspektive auf. Zudem unterstreichen Sie die verbale Kommunikation und werden auch von Menschen ohne technischem Hintergrund verstanden.
Auf unserer Themenseite gibt es weitere Informationen zur Agilen Produktentwicklung.
