Was macht eine Produktentwicklung erfolgreich? Richtig, wenn die verschiedenen Wünsche und Anforderungen der Nutzer erfüllt werden. Scrum User Stories sind ein gutes Werkzeug, um agile Projekte inhaltlich zu steuern. Denn Entwickler verstehen durch die Nutzergeschichten, was genau der Nutzer will – und warum überhaupt.
Was sind User Stories bei Scrum?
Laut Definition beschreibt eine Scrum User Story die Anforderungen, die ein Anwender an ein Produkt stellt. Diese Anforderungen an die Funktionalität werden in den User Stories so präzise und einfach wie möglich beschrieben, sodass jeder im Scrum-Team sie gut verstehen kann.
User Stories transportieren also Erwartungen an die Funktionalität von Software oder andere Produkte, die durch agile Projekte realisiert werden. Sie geben allerdings keine technischen Lösungen vor, die die Entwickler zum sturen Realisieren zwingen würden.
Wozu werden User Stories genutzt?
User Stories sind ein wichtiger Bestandteil der Produktentwicklung. So bleibt der Benutzer nämlich im Fokus und das Team konzentriert sich darauf, die Probleme echter Anwender zu lösen.
Die Vorteile von User Stories auf einen Blick:
- Transparenz: Entwickler können mit Stakeholdern (also Nutzern oder Kunden) deren Bedürfnisse diskutieren, validieren und mit einem gemeinsamen Verständnis an der Umsetzung arbeiten. Damit reduzieren sie das Risiko, dass Anforderungen falsch verstanden werden.
- Agilität: Durch Scrum User Stories verbessern Scrum-Teams ihre Schätzungen und ihre Sprint-Planung und erreichen dadurch präzisere Prognosen und höhere Agilität.
- Zusammenarbeit: Wenn ein Endziel festgelegt ist, kann das Team an einem Strang ziehen und entscheiden, wie es dem Benutzer am besten gerecht wird und das Ziel erreicht.
- Kreativität: User Stories fördern kreative Lösungen, denn sie animieren das Team, kritisch und „out of the box“ über die beste Lösung nachzudenken.
Epics, Storys, Tasks – was ist was?
Scrum User Stories sind im Scrum-Prozess zwischen Epics und Tasks zu verorten. Um damit gut arbeiten zu können, sollten sie also weder zu groß noch zu klein sein.
Epic
Epics umfassen die groben Teilbereiche eines Produktes, wie etwa den Produktbereich eines Online-Shops. Ein Epic ist also eine User Story auf höchster Abstraktionsstufe, die vom Product Owner in mehrere Stories aufgeteilt wird. Epics sorgen dafür, dass die tägliche Arbeit des Entwicklungsteams an den Stories einen Beitrag zu den Unternehmenszielen leistet. Dabei umfassen sie deutlich mehr als einen Sprint, um entwickelt und getestet zu werden und sind ganz allgemein formuliert — ohne auf die Details einer Anforderung einzugehen.
Story
Eine Story enthält die Anforderungen von Nutzern, geschrieben als kleine handhabbare Texte. In unserem Beispiel könnte das etwa eine Suchfunktion im Produktbereich des Online-Shops sein. Auf dieser Basis schätzt das Team den Realisierungsaufwand ein.
Task
Um die bereits diskutierten und nach Aufwand geschätzten Anforderungen umzusetzen, erstellt das Entwicklerteam jetzt kleine Tasks, die im Sprint Backlog zu finden und meistens innerhalb eines Tages umsetzbar sind. Wenn eine Aufgabe eine vereinbarte Zeitspanne überschreitet, kann sie in zusätzliche Aufgaben aufgeteilt werden. Eine Story ist dann erledigt, wenn alle Aufgaben erledigt sind.
Welche Bestandteile hat eine User Story?
Ganz konkret beantwortet eine User Story die Fragen „Wer?“ möchte „Was?“ und „Warum?“: Als <ROLLE> möchte ich <FUNKTION>, um damit <NUTZEN> zu erzielen.
Rolle
Wie detailliert die Definition der Rolle ist, hängt sowohl von der User Story als auch von der Reife des Vorhabens ab. So kann die gleiche Rolle beispielsweise für unterschiedliche Personas gelten und das Verhältnis zu einem Produkt beschreiben. Für den passenden Detailgrad gibt es kein richtig oder falsch – das Wichtigste ist, dass für das Team mit der gewählten Rolle eine aussagekräftige User Story entsteht.
Funktion
Die Funktion beschreibt die Erwartungen, Ziele und Wünsche des Nutzers. Damit wird also die Frage beantwortet, was der Kunde braucht. Wenn ein Produkt bereits auf dem Markt angeboten wird, werden vom Nutzer mit Sicherheit viele gewünschte Funktionen an das Produkt gestellt. In frühen Phasen eines Projektes lassen sich dagegen oft nur Annahmen formulieren, welche Funktion der Nutzer erwartet.
Je klarer und präziser die Funktion in die User Story eingeht, desto hilfreicher ist diese für das Entwicklerteam, um die Anforderungen zu realisieren.
Nutzen
Mit der Formulierung des Nutzens wird die Frage nach dem „Warum?“ beantwortet – und ohne diesen Zusatz ist eine User Story nicht komplett. Hierdurch kommt nämlich erst zum Ausdruck, warum die Funktion für die Rolle überhaupt wichtig ist und welchen Mehrwert die Erfüllung der User Story schafft. Anforderungen aufzunehmen ist noch relativ einfach – zum Beispiel, weil der Kunde mehrfach danach gefragt hat – aber zu verstehen, warum das für ihn wichtig ist, gibt den notwendigen Kontext.
Wie sollte eine Scrum User Story formuliert sein?
Gute User Stories werden mit einigen Sätzen in einfacher Sprache verfasst, um ein gewünschtes Ergebnis zu beschreiben, ohne ins Detail zu gehen. Bei der Formulierung sind vor allem diese vier wichtigen Kriterien zu beachten:
1. User Stories werden vertikal formuliert.
Stellen Sie sich eine Torte vor. Statt horizontal durch die Torte zu schneiden, ist ein vertikaler Schnitt sehr viel sinnvoller (und leckerer), um Tortenstücke mit allen Schichten zu erhalten. Das trifft auch auf User Stories zu. Unterschiedliche Bereiche eines technischen Systems, wie zum Beispiel Frontend und Backend, sollten mit adressiert werden. Dann steht am Ende eines Sprints dem Kunden eine Funktionalität zur Verfügung, die vollständig nutzbar ist.
2. User Stories konzentrieren sich auf den größten Nutzen.
Bei der Erstellung der User Stories sollte immer die Frage gestellt werden: Besitzt die Anforderung einen simplen Kern und verspricht dieser den größten Nutzen?
3. User Stories verringern Komplexität.
User Storys sollen einem Scrum-Team helfen, Optionen zu verringern. Wenn der Anwender zum Beispiel keine komplexe Oberfläche benötigt, ist es zum Beispiel möglich, mit einem schlichten und einfachen Design zu starten.
4. User Stories werden nach bestimmten Kriterien aufgeteilt.
Umfangreiche User Stories sollten nach Funktionen, Aktionen oder Operationen aufgeteilt werden, die der Benutzer separat ausführen kann.
Konkrete Beispiele von Scrum User Stories sind:
- Als User möchte ich meine Freunde einladen, damit wir den Service gemeinsam nutzen können.
- Als Mitarbeiter möchte ich meine Arbeit organisieren, damit ich mehr Kontrolle darüber habe.
- Als Vorgesetzter möchte ich die Fortschritte meiner Kollegen nachvollziehen können, damit ich über unsere Erfolge und Fehlschläge berichten kann.
Wie groß sollte eine Scrum User Story sein?
Für Scrum-Teams ist es eine große Herausforderung, Backlog-Einträge in die richtige Größe zu bringen. User Stories sind hierbei eine große Hilfe, weil sie den Fokus auf einen echten Mehrwert für den Nutzer setzen. So werden dann in Scrum mit User Stories Sprints definiert und im Verlauf des Sprints “abgearbeitet”.
Die Praxis hat dabei gezeigt, dass eine gute Größe erreicht ist, wenn eine User Story vom Team innerhalb einer Woche fertiggestellt werden kann. Sind User Stories zu umfangreich, kann das Team den Aufwand kaum verlässlich abschätzen. Dann spaltet der Product Owner die Anforderungen in kleinere Einheiten.
Wichtig zu beachten: Gemeint ist hier nicht die investierte Arbeitszeit, sondern die Dauer vom Beginn der Arbeit bis zum Zustand “Fertig” nach der „Definition of Done“. So eine Definition wird zwar nicht im Scrum Guide erwähnt, ist aber für viele Scrum-Teams eine große Hilfe und wird häufig verwendet.
Woran erkennt man eine gute Scrum User Story?
Eine gute Scrum User Story sollte alle Kriterien der INVEST-Formel erfüllen: Sie ist independent (unabhängig), negotiable (verhandelbar), valuable (wertvoll), estimable (schätzbar), short (kurz genug für einen Sprint) und testable (überprüfbar).
Unabhängig
Independent: Die User Story beschreibt Funktionen, die schon für sich allein implementiert werden können. Jede einzelne Story sollte also unabhängig von einer anderen Story sein und die Umsetzung darf nicht voraussetzen, dass vorher eine andere Story umgesetzt wurde.
Verhandelbar
Negotiable: Anders als bei herkömmlichen Projekten ist die User Story nicht vollständig vordefiniert, sondern verhandelbar. Somit erhält das Entwicklungsteam den Freiraum, eine User Story nach eigenem Ermessen möglichst optimal umzusetzen.
Nützlich
Valuable: Storys müssen nützlich sein und somit einen Mehrwert für den Endkunden bieten. Hat eine Story keinen Wert, dann sollte man im besten Fall auf sie verzichten.
Schätzbar
Estimated: Storys können dafür sorgen, dass das Team die Komplexität und die erforderlichen Kapazitäten einschätzen können, um die User Story realisieren zu können.
Kurz
Short: Die Umsetzung der User Story darf nicht mehr Zeit in Anspruch nehmen als eine Sprintlänge.
Testbar
Testable: Die Stakeholder und der Product Owner kennen den Inhalt der User Story genau und wissen, welche Inhalte in Tests bewertet werden. Dies wird in den Abnahmekriterien und der „Definition of Done“ formuliert.
Was sagt der Scrum Guide zur User Story?
Wäre das Format Pflicht für Scrum-Teams, dann müsste es auch im Scrum Guide stehen.
Der Scrum Guide spricht aber nur von Product Backlog-Einträgen und gibt keine Definition von User Storys. Grundlegend lässt sich also sagen, dass Scrum-Teams laut Scrum Guide nicht das User Story Format nutzen müssen.
Fazit
Ein Nutzer interessiert sich herzlich wenig dafür, ob für die Implementierung einer Software eine Datenbank, ein Microservice oder andere technische Komponenten benötigt werden. Entscheidend für den Erfolg ist allein, was das Produkt für ihn leistet. Um Kunden zu verstehen, sind User Storys deshalb unverzichtbar.
Dieses einfache aber wirkungsvolle Format macht es möglich, Bedürfnisse zu verstehen, zu überprüfen und sich mit einem gemeinsamen Verständnis an die Umsetzung zu machen. Und um auch den letzten Zweifler zu überzeugen: Der Aufwand, eine User Story zu formulieren, ist so gering, dass sich eine Diskussion fast nicht lohnt, ob ihr Einsatz überhaupt Sinn macht.
Eine Nutzergeschichte beschreibt die Erwartungen eines Nutzers an ein Produkt. Im Kern besteht sie aus den folgenden Elementen: Als <ROLLE> möchte ich <FUNKTION>, um damit <NUTZEN> zu erzielen.
Scrum User Stories sind ein wichtiger Bestandteil der Produktentwicklung. So bleibt der Nutzer im Fokus und das Team konzentriert sich darauf, die Probleme echter Anwender zu lösen.
Gute Stories werden mit einigen Sätzen in einfacher Sprache verfasst, um ein gewünschtes Ergebnis zu beschreiben, ohne ins Detail zu gehen. Dabei sollten sie alle Kriterien der INVEST-Formel erfüllen, also unabhängig, verhandelbar, nützlich, schätzbar, kurz genug für einen Sprint und überprüfbar sein.
Eine User Story sollte vom Team innerhalb einer Woche bzw. innerhalb einer Sprintlänge fertiggestellt werden können.
