User Stories: Damit agile Projekte von Beginn an auf der richtigen Spur sind
In der Anfangsphase agiler Projekte mit Scrum oder Kanban ist die Erstellung von User Stories von größter Bedeutung. Denn diese aus Sicht der Nutzer formulierten, kurzen Storys fokussieren deren Erwartungen an das Produkt und bringen auf den Punkt, welchen Mehrwert bzw. Nutzen eine bestimmte Funktionalität für sie generieren soll. Damit werden User Stories zu wichtigen Leitplanken für das Team, da sie für Struktur, Transparenz und ein gemeinsames Verständnis des Gesamtvorhabens sorgen. Eine Einführung ins Thema.
In diesem Artikel behandelte Themen
- Agiles Projektmanagement lässt die Nutzer zu Wort kommen
- Was sind User Stories im agilen Projektmanagement?
- Unabdingbar für die optimale Verständigung in agilen Projekten
- Wichtige Weichenstellung in der Anfangsphase des Projekts
- Akzeptanzkriterien: Wann gilt eine User Story als abgeschlossen?
Ziel des Beitrags: Projektmanager, Entwicklungsteam und Stakeholder erfahren, inwiefern User Stories dazu beitragen, dass agile Projekte erfolgreich verlaufen.
Agiles Projektmanagement lässt die Nutzer zu Wort kommen
Agiles Projektmanagement ist heutzutage eine unverzichtbare Herangehensweise für Unternehmen, um flexibel auf sich dynamisch ändernde Marktbedingungen reagieren zu können. Auf den Punkt genau formulierte Anforderungen schaffen dabei die Basis für die Entwicklung innovativer Lösungen und Produkte. Sie definieren die Funktionen, Eigenschaften und Qualitätsstandards, die ein Produkt erfüllen muss, um den Bedürfnissen der Benutzer später tatsächlich gerecht zu werden.
Agile Methoden wie Scrum und Kanban stellen daher konsequent die Erwartungen der Benutzer in den Mittelpunkt – und hier kommt die sogenannte User Story ins Spiel. Im agilen Projektmanagement sind diese User Stories eine wahre Wunderwaffe, da sie gleich zu Anfang die Richtung vorgeben.
Im Folgenden erklären wir, was sich hinter dem Begriff „User Story“ verbirgt und wie User Stories in den ersten Phasen von Projekten erstellt werden müssen, um die Grundlage für eine erfolgreiche Umsetzung des Vorhabens durch das Team zu legen.
Wer sich detailliert über agile Prinzipien, Methoden und Tools informieren möchte und an der Arbeitsweise unserer Digitalagentur blindwerk interessiert ist, dem bietet die „timeBOXED-Serie über agiles Projektmanagement“ viele interessante Insights.
Was sind User Stories im agilen Projektmanagement?
Im agilen Projektmanagement sind User Stories aus Sicht des Benutzers formulierte, kurze und prägnante Beschreibungen der Funktionen eines Produkts bzw. der Anforderungen an ein Produkt. Durch ihre granulare Form unterscheidet sich die User Story wesentlich von traditionellen, weitaus detaillierteren Anforderungsspezifikationen, die in agilen Projekten eher hinderlich sind, da mit ihnen kein ausreichend flexibles Anforderungsmanagement durchführbar ist. Im Vergleich zum klassischen Lastenheft etwa ermöglichen User Stories eine höhere Flexibilität in agilen Umgebungen bzw. eine bessere Anpassungsfähigkeit an sich verändernde Anforderungen.
Eine User Story ist für gewöhnlich in natürlicher Sprache verfasst und folgt einem bestimmten Format, das typischerweise lautet: „Als [Benutzerrolle] möchte ich [Funktionalität], damit [Nutzen]“.
- Die Benutzerrolle in der User Story beschreibt, wer die Funktionalität verwenden möchte. Es kann sich um einen bestimmten Benutzertyp handeln, wie beispielsweise ein Kunde, ein Administrator oder ein Mitarbeiter.
- Die Funktionalität in der User Story beschreibt, was der Benutzer tun möchte oder welche Aktion durchgeführt werden soll. Es handelt sich um die konkrete Aufgabe oder Handlung, die die Benutzerrolle ausführen möchte.
- Der Nutzen in der User Story beschreibt, warum die Benutzerrolle die beschriebene Funktionalität benötigt oder welche Vorteile sie daraus ziehen soll. Es geht um den Mehrwert bzw. Nutzen, den die Erfüllung dieser Anforderung für den Benutzer hat.
Statt sich auf technische Details und deren konkrete Realisierung zu konzentrieren, liegt der Fokus der User Story also darauf, was der Benutzer tun möchte und warum. Somit lässt sie dem Entwicklungsteam Raum für Interpretation und Kreativität.
Das Konzept der User Stories stammt aus der agilen Softwareentwicklung und wurde in den frühen 2000er Jahren von Kent Beck und anderen Praktikern des Extreme Programming (XP) entwickelt.
User Stories – Drei einfache Beispiele
Beispiel 1: Als Online-Shopper möchte ich meine Bestellhistorie einsehen können, damit ich meine vergangenen Einkäufe nachverfolgen kann.
Beispiel 2: Als Website-Besucher möchte ich Suchfilter verwenden können, um die angezeigten Produkte nach bestimmten Kriterien zu filtern.
Beispiel 3: Als Administrator möchte ich Benutzerkonten verwalten können, um die Zugriffsrechte zu steuern und die Sicherheit zu gewährleisten.
Unabdingbar für die optimale Verständigung in agilen Projekten
User Stories helfen, den Umfang des Projekts zu definieren und dessen Ziele klar zu kommunizieren. Als Leitfaden für die Entwicklung ermöglichen sie es dem Team, sich auf die Implementierung der wichtigsten Funktionen zu konzentrieren, die den größten Nutzen für die Benutzer bringen. Darüber hinaus fördern User Stories die Zusammenarbeit zwischen dem Team und den Stakeholdern, indem sie eine gemeinsame Sprache und ein gemeinsames Verständnis für die verschiedenen Funktionalitäten des Produkts schaffen
Klar ist: Ohne User Stories ließen sich mit agilen Methoden wie Scrum und Kanban keine effizienten Iterationen durchführen. Denn sie sind eine wichtige Voraussetzung sowohl für die Planung, Priorisierung und Umsetzung einzelner Aufgaben als auch für die Planung, Strukturierung und Steuerung des gesamten Projekts. Unmittelbar nach dem Start eines Projekts kommt dem gewissenhaften Erstellen von User Stories daher eine überragende Bedeutung zu.
Große, übergeordnete Anforderungen werden Epics genannt. Diese sind oft in kleinere, detailliertere User Stories unterteilt und dienen dazu, den Gesamtumfang des Projekts zu definieren und große Funktionsbereiche zu erfassen. Auf diese Weise bieten Epics eine strategische Perspektive auf die Projektziele, während User Stories gewissermaßen einzelne Taktiken darstellen, um diese Ziele zu erreichen.
Wichtige Weichenstellung in der Anfangsphase des Projekts
Nachdem die Anforderungen in Zusammenarbeit mit den Stakeholdern identifiziert und priorisiert wurden, werden die ersten, zunächst noch „groben“ User Stories erstellt. Dies geschieht typischerweise in Workshops, in denen das Team und die Stakeholder gemeinsam die verschiedenen Funktionen und Use Cases des zu entwickelnden Produkts durchgehen. Zur weiteren Spezifizierung der User Stories kommt häufig die Methode des User Story Mappings zum Einsatz.
Mit User Story Mapping lassen sich die einzelnen User Stories entlang der Benutzerreise oder des Arbeitsablaufs visualisieren und strukturieren. Dabei werden die User Stories in einer horizontalen Abfolge angeordnet, die den Ablauf der Benutzerinteraktionen widerspiegelt. Die Funktionen und Aufgaben des Produkts werden vertikal dargestellt. Auf diese Weise entsteht eine Übersicht über die verschiedenen Funktionen und Use Cases des Produkts, was es dem Team ermöglicht, einen gemeinsamen Rahmen für die Entwicklung zu schaffen.
Wenn das User Story Mapping beendet ist, werden die einzelnen User Stories genauer definiert, verfeinert und im oben erwähnten Format formuliert.
Wichtig: Eine User Story sollte eine angemessene Granularitäthaben, also nicht zu groß oder zu klein sein. Hier ist ein geeigneter Mittelweg zu finden, der es dem Team ermöglicht, die Arbeit effizient zu planen und umzusetzen.
Danach wandert die fertige User Story ins Product Backlog. Erst jetzt können Projekte in die heiße Phase übergehen, und das Team kann mit der ersten Iteration beginnen. Zuvor ist aber noch jede User Story mit Akzeptanzkriterien zu versehen. Dazu weiter unten mehr.
So startet blindwerk in agile Projekt
Auch bei blindwerk läuft in der Anfangsphase agiler Projekte alles auf die Erstellung von User Stories und Epics hinaus. Dabei durchlaufen die Projekte in der Regel die folgenden Schritte, damit das Produkt Benutzern später einen größtmöglichen Nutzen bietet:
- Chemistry Meeting
- Kick-off-Workshop
- Kennenlernen aller Stakeholder
- Analyse der kundenspezifischen Begebenheiten, Geschäftsbereiche sowie bereits verfügbare Infrastruktur (analog und digital)
- Erarbeitung der Projektvision bzw. der Diskussion eines möglichen Zielsystems
- Ramp-up-Phase
- Verarbeitung der Ergebnisse des Workshops
- Aufsetzen benötigter Tools und Systeme (Jira, Confluence etc.)
- Erarbeitung eines ersten Ramp-up-Konzepts der Umsetzung
- Architektur
- Beschreibung der Kern-Use-Cases/Business-Use-Cases
- Definition erster User Stories
- Präsentation und Konkretisierung: Ramp-up-Konzept
- Vorstellung des Ramp-up-Konzepts
- Diskussions- und Feedbackrunde
- Epic-Phase
- Verarbeiten der Ergebnisse und des Feedbacks aus der Vorstellung des ersten Ramp-up-Konzepts
- Definition aller User-Stories und Epics
- Präsentation und Konkretisierung: Epics
- Präsentation Wireframes, Zielsystem und Kostenrahmen
Akzeptanzkriterien: Wann gilt eine User Story als abgeschlossen?
Eine User Story kann nach einer (oder mehr) Iterationen erst dann als abgeschlossen betrachtet werden, wenn die Funktionalität rundum den Erwartungen der Benutzer entspricht und deren Nutzen gegeben ist. Dazu müssen spezifische Bedingungen erfüllt sein: die sogenannten Akzeptanzkriterien.
Akzeptanzkriterien präzisieren die User Story in Form einer „Definition of done“ und schaffen ein gemeinsames Verständnis darüber, ab welchem Punkt die jeweilige Aufgabe bzw. das jeweilige Aufgabenpaket als erfolgreich gelöst/abgearbeitet gilt.
Beispiele für Akzeptanzkriterien in einem Webprojekt:
- Die neue Funktionalität muss in allen gängigen Webbrowsern funktionieren.
- Alle Eingabefelder müssen validiert werden, um sicherzustellen, dass nur gültige Daten akzeptiert werden.
- Die Antwortzeit der Seite darf nicht länger als drei Sekunden betragen, um eine reibungslose Benutzererfahrung zu gewährleisten.
Die Akzeptanzkriterien dienen also als Grundlage für Tests und Validierungen und unterstützen die Qualitätssicherung im Entwicklungsprozess, und sie werden in Zusammenarbeit des Teams mit den Stakeholdern identifiziert und festgelegt. Jede einzelne User Story im Product Backlog hat dabei spezifische bzw. eigene Akzeptanzkriterien.
Am Ende des Tages sind es eben diese Akzeptanzkriterien, die den Maßstab für den Erfolg einer User Story setzen und sicherstellen, dass das Ergebnis die Erwartungen der Benutzer erfüllt – eine Grundvoraussetzung für eine gelungene Umsetzung des Projekts im agilen Entwicklungsprozess.
Ihr Unternehmen möchte agile Projekte mit Scrum oder Kanban durchführen und braucht auch beim Thema User Story einen passenden Sparringspartner? Dann vereinbaren Sie zwecks unverbindlicher Kontaktaufnahme gerne ein Chemistry Meeting mit unserer Digitalagentur blindwerk!