User Stories: Vorteile, Beispiele und das 3-C-Modell

Was sind User Stories?

User Stories sind eine hilfreiche agile Methode, um Anforderungen und Bedürfnisse an ein Produkt oder eine Leistung aus Nutzersicht zu beschreiben. Sie haben ihren Ursprung im Extreme Programming: Kent Beck, einer der Begründer der Softwaretechnik, setzte das Konzept in Form von „Story Cards“ erstmals 1996 in einem Projekt ein.

Eine User Story ist aus Perspektive von Kund*innen bzw. Nutzer*innen formuliert. Sie beschreibt den Mehrwert, der für die Nutzer*innen entsteht, wenn die Story (durch eine entwickelte Lösung) umgesetzt ist. User Stories folgen einem klaren Aufbau und erzählen: WER möchte WAS und WARUM möchte er oder sie es?.

Für die Formulierung nutzen agile Teams häufig eine Art Satzschablone:

User Stories in Scrum

Auch wenn sie im Scrum Guide nicht erwähnt werden, haben sich User Stories in der Praxis von Scrum-Teams als Werkzeug etabliert. In der (Produkt-)Entwicklung sammeln Scrum-Teams ihre Anforderungen und Aufgaben in einem Product Backlog. Hierin finden sich neben User Stories weitere sogenannte Backlog Items (z. B. Tasks oder Epics).

Im Scrum-Kontext beschreiben User Stories einzelne Produkt-Features, die einen Zwischenschritt in der Entwicklung darstellen und bereits einen Wert für die Nutzer*innen liefern. Üblicherweise definiert das Team die Story so, dass sie innerhalb eines Sprints erledigt werden kann. Ein Scrum-Sprint ist ein fest gelegter Zeitraum, in dem das Team ein bestimmtes Arbeitspaket erledigt.

User Stories in anderen Frameworks

Aber nicht nur in Scrum, auch in anderen agilen Frameworks hat sich die Technik bewährt. So nutzen beispielsweise auch Teams, die mit Kanban arbeiten, User Stories für die Formulierung ihrer Anforderungen. Generell eignet sich die Methode für alle (agilen) Vorgehensmodelle, die auf eine kundenzentrierte Lösungsfindung und Entwicklung setzen.

Was beinhaltet eine User Story?

User Stories sollten kurz und möglichst prägnant formuliert sein. Sie bestehen zunächst einmal aus einem Satz in dem oben beschriebenen Muster. Enthalten sind darin Informationen über den Nutzer, sein Bedürfnis bzw. Anforderung und den erhofften Mehrwert. In der Regel benötigt das Team zusätzliche Informationen, um die User Story zu erfüllen. Diese klären sich im Gespräch zwischen Product Owner und Team. Gegebenenfalls beziehen sie hierzu auch Kund*innen oder Auftraggeber mit ein.

Im Rahmen der Klärung werden die User Stories mit weiteren Informationen zur Anforderung, Ansprechpartnern und Akzeptanzkriterien angereichert. Akzeptanzkriterien sind (fachliche) Bedingungen, die eine Story erfüllen muss, um als abgeschlossen zu gelten.

Die „3 Cs“ der User Story 

Mit dem 3-C-Modell hat Ron Jeffries, neben Kent Beck einer der Gründer von Extreme Programming, die wichtigsten Regeln für gute User Stories aufgestellt. Die „3 Cs“ stehen für „Card“, „Conversation“ und „Confirmation“:

1. Card (Karte): Viele Teams arbeiten mittlerweile mit digitalen Tools (z. B. Asana, Notion, Jira, Trello), um User Stories zu formulieren und im Backlog zu sammeln. Dennoch hat sich das „Karten-Kriterium“ bewährt. Hiermit können Teams bewerten, ob eine User Story die richtige Länge hat oder möglichweise zu groß ist. Ursprünglich wurden die Stories auf Karteikarten geschrieben. Und die bieten nur begrenzten Platz. Deswegen sollte die User Story möglichst prägnant sein – und natürlich trotzdem die wichtigen Informationen transportieren (Rolle, Funktion, Mehrwert). Als Faustregel gilt: Ist der Satz zu lang und passt nicht auf eine DIN-A5-Karte, ist die Story wahrscheinlich zu komplex. In diesem Fall zerteilen Sie sie in zwei oder mehrere User Stories. Diesen Vorgang nennt man User Story Splitting.
2. Conversation (Konversation, Kommunikation): Das Team muss verstehen, wie es die User Story umsetzt. Deshalb sprechen Product Owner und Team mindestens einmal über die Story, bevor es an die Arbeit geht. Dies findet im Scrum-Team im Backlog Refinement statt. In diesem regelmäßigen Meeting kümmert sich das Team um die Einträge im Backlog, arbeitet diese weiter aus und versorgt sie mit zusätzlichen Informationen. Um Klarheit über die Story zu erhalten, können auch Stakeholder*innen (z. B. Kund*innen oder Auftraggeber) zu diesen Gesprächen eingeladen werden. Je nach Umfang wird die User Story mehrmals besprochen und mit detaillierteren Informationen ausgestattet.
3. Confirmation (Bestätigung): Für jede User Story stellt das Team Akzeptanzkriterien auf. Sind diese erfüllt, gilt dies als Bestätigung, dass die Story erfolgreich umgesetzt ist. Dies überprüft das Team beispielsweise mit Akzeptanztests.

INVEST-Kriterien: Was macht eine gute User Story aus?

Zusätzlich zu den 3 Cs lässt sich die Qualität einer User Story auch mit den 6 sogenannten „INVEST-Kriterien“ von Bill Wake überprüfen. „INVEST“ ist ein Akronym und steht für folgende sechs Merkmale:

• Independent (unabhängig): Die User Story ist unabhängig von anderen Stories umsetzbar.
• Negotiable (verhandelbar): Eine User Story ist nicht in Stein gemeißelt. Im Rahmen der gemeinsamen Gespräche zwischen Product Owner, Team und Stakeholder*innen kann die Story weiterentwickelt und präzisiert werden.
• Valuable (wertvoll): Das Ergebnis der User Story stiftet einen Mehrwert für Nutzer*innen oder Kund*innen.
• Estimable (schätzbar): Das Team muss den Aufwand für die Umsetzung der Story schätzen können.
• Small (klein): Der Umfang der Story erlaubt es, sie innerhalb eines Scrum-Sprints umzusetzen.
• Testable (prüfbar): Die User Story hat Akzeptanzkriterien, die geprüft werden können.

Wer schreibt die User Stories?

Im Scrum-Team formuliert in der Regel der Product Owner die User Stories. Oft geschieht dies in Abstimmung mit dem Team, das zusätzliche Informationen aus einer Umsetzungsperspektive einbringt. Bei der Formulierung spielen fließen zudem die Anforderungen von Stakeholder*innen ein (z. B. Nutzer*innen oder Unternehmensvertreter), für die der Mehrwert geschaffen werden soll.

Im Interview beschreibt Mathias Kruse, Product Owner bei Gieseke+Devrient, die Vorgehensweise in seinem Team: „Da ich die Anforderungen sammele, schreibe ich die User Stories – allerdings auf einem relativ hohen, abstrakten Level. Daraus leiten sich die Entwickler dann ihre eigenen Stories ab, die dann auf einer Umsetzungsebene geschrieben sind.“

Wichtig: User Stories sollten nicht einfach geschrieben und dann ins Team delegiert werden. Sie stellen vielmehr eine Einladung zum Gespräch dar, stehen am Anfang der Entwicklung und bilden das zu erreichende Ziel ab. Im Gespräch klären Product Owner und Team, wie die Story zu verstehen ist und was sie mit sich bringt.

Welche Vorteile bieten User Stories?

User Stories stellen Nutzer*innen bzw. Kund*innen in den Mittelpunkt. Die Methode ermöglicht es dem Entwicklungsteam, sich in die Rolle der Zielgruppe zu versetzen und deren Perspektive einzunehmen. Im Gegensatz zu Anforderungen definieren User Stories nicht, was wie gemacht werden soll. Sie erzählen, für wen welcher Mehrwert geschaffen wird. User Stories „zwingen“ Sie dazu, sich mit Ihren Nutzer*innen auseinander zu setzen und herauszufinden, was für diese wirklich wichtig ist.

Die wichtigsten Vorteile von User Stories:

1. Bilden die Nutzersicht ab
2. Sie sind kompakt und meist schnell geschrieben: Der Fokus liegt auf dem Wert für die Nutzer*innen und nicht auf der Idee. Wenn ein Team erkennt, dass die Idee keinen Mehrwert stiftet, schmerzt es nicht, die User Story zu verwerfen. Da die Erstellung der Story in der Regel wenig Zeit und Energie gekostet hat, hält auch der Urheber der Story nicht krampfhaft an ihr fest.
3. Sie sind anpass – und erweiterbar: Stories können im Laufe der Recherche umformuliert, mit zusätzlich Informationen erweitert und verändert werden. Sie sind keine in Stein gemeißelten Anordnungen.
4. Sorgen als Standard im Team für eine bessere Ergebnisqualität: Die festgelegte Form der Stories sorgen dafür, dass sich das Team inhaltlich mit dem Thema auseinandersetzen kann. Durch die teaminterne Klärung der Story sprechen alle im Team die gleiche Sprache und jeder weiß, was erreicht werden soll.
5. Sie fördern die Selbstorganisation im Team.

User Stories fördern selbstorganisierte Arbeit im Team

Eine User Story definiert ein Ziel, anstatt Aufgaben oder Lösungen vorzugeben: Welchen Mehrwert erzeugen wir für wen? Das ist die zentrale Frage, die sich das Entwicklungsteam stellt. Eine User Story sagt aber nicht, wie oder auf welchem Weg es dieses Ziel erreichen soll. Das entscheidet das Team eigenständig.

Kommen wir noch einmal zurück auf unser Beispiel. Eine User Story lautete: „Als Interessent*in möchte ich einen Überblick über die Konferenzinhalte erhalten, um eine Entscheidung über eine Teilnahme zu treffen.“ Für das Team ergeben sich hieraus mehrere Optionen für eine Lösung. Ob nun eine Veranstaltungsbroschüre gedruckt wird oder das Programm auf einer Webseite einsehbar ist, hängt maßgeblich von der angesprochenen Zielgruppe ab.

In diesem Sinne fördern User Stories die Selbstorganisation agiler Teams. Die Teammitglieder bekommen keine Lösungen vorgegeben, sondern entscheiden in kollaborativer Zusammenarbeit, welche Arbeiten für die Umsetzung der Story nötig sind. Sie leiten Aufgaben aus der Story ab und legen auch den Zeitraum fest, in denen sie die Aufgaben bearbeiten. Es erfolgt zudem keine Zuteilung der Arbeiten. Einzelne Teammitglieder nehmen sich die Aufgaben, die sie erledigen können (und möchten).

Fazit

User Stories sind ein hilfreiches Werkzeug für eine kundenzentrierte Produktentwicklung und Lösungsfindung. Die agile Methode stellt den Nutzer der zu entwickelnden Lösung in den Mittelpunkt. Das Entwicklungsteam bekommt keine Aufgaben vorgegeben. Es entscheidet eigenständig, welche Arbeiten nötig sind, um die User Story umzusetzen. So fördern User Stories die selbstorganisierte Arbeit agiler Teams.