Das Scrum Framework — Zweite Ausgabe

Dieses Kapitel bewahrt den historischen und praktischen Lehrkontext der zweiten Ausgabe. Den Lehrplan der dritten Ausgabe finden Sie ebenfalls im nachfolgenden Inhaltsverzeichnis.

---

Scrum User Stories: umfassender Überblick für eine wirksame Verwaltung

Definition: Eine Scrum User Story ist eine kurze, nutzerzentrierte Beschreibung einer gewünschten Funktion in einem agilen Scrum-Projekt. Sie wird häufig für Product-Backlog-Einträge verwendet, ist aber kein vorgeschriebenes Format des Frameworks. Aus Sicht der Endnutzer beschreibt sie das Wer, Was und Warum einer Anforderung und betont Zusammenarbeit und Kommunikation im funktionsübergreifenden Team. Die einfache Vorlage enthält Nutzerrolle oder Akteur, gewünschte Handlung oder Ziel sowie Nutzen oder Wert. User Stories schaffen gemeinsames Anforderungsverständnis, unterstützen inkrementellen Fortschritt und ermöglichen Priorisierung nach Nutzerbedürfnissen und Feedback.

Scrum User Stories sind wie kurze, einfache Filmhandlungen für jede benötigte Produktfunktion. Jede Story enthält eine Figur, also Nutzer oder Akteur, ein Ziel, die gewünschte Funktion, und den Grund dafür, also den Nutzen.Stellen Sie sich vor, diese einzelnen Geschichten verbinden sich zu einem Netz aus Wünschen, Erwartungen und Lösungen: dem Backlog. Seine Verwaltung, Priorisierung und Verfeinerung gleicht der Regie eines Films, in dem jede Geschichte wichtig und zugleich veränderlich ist. Das International Scrum Institute begleitet Sie dabei, diese User Stories und ihre wirksame Verwaltung zu beherrschen.

Für eine klare, wirksame User Story verwenden Sie beispielsweise: „Als [Rolle] möchte ich [Fähigkeit], damit [Nutzen].“ Zum Beispiel: „Als Kunde möchte ich meinen Bestellstatus leicht verfolgen können, damit ich meinen Zeitplan entsprechend gestalten kann.“

Merkmale von Scrum User Stories

Einträge im Scrum Product Backlog werden häufig als User Stories formuliert. Ihr wichtigstes Merkmal ist eine kurze Geschichte darüber, wie jemand das Produkt nutzt. Sie enthalten einen Namen, eine kurze Erzählung sowie Akzeptanzkriterien und Abschlussbedingungen. Ihr Vorteil ist der genaue Fokus auf Bedürfnisse und Wünsche der Nutzer, ohne die technische Umsetzung im Detail vorzugeben.

Es gibt verschiedene Empfehlungen zur Definition von User Stories. Eine mögliche Vorlage lautet:

Als [Akteur] [möchte|muss] ich [Handlung], damit [Ergebnis]
Oder kürzer:
Als [Akteur] [möchte|muss] ich [Ergebnis]

Akteur: Die Person oder Persona, deren Bedürfnis die Story beschreibt, nicht die für das Backlog verantwortliche Person. Häufig ist dies ein Nutzer, doch mehr Präzision hilft: „Administrator“, „angemeldeter Kunde“ oder „nicht authentifizierter Besucher“ erleichtern das Verständnis und stellen den Kontext her.

Handlung: Was der Akteur tun möchte. Bei einer verpflichtenden Handlung kann „muss“ verwendet werden, ansonsten „möchte“.

Ergebnis: Was der Akteur durch die Handlung erreichen möchte. Dies ist das Ergebnis der Ausführung aus seiner Sicht.

Scrum User Story: ein Überblick

Im dynamischen agilen Projektmanagement sind User Stories ein wichtiges Werkzeug, um Kundenanforderungen wirksam zu vermitteln. Sie machen abstrakte Anforderungen lebendig, indem sie diese aus Sicht der Endnutzer beschreiben.

Es sind kurze, informelle Funktionsbeschreibungen mit klaren Bedürfnissen der Endnutzer, also der Akteure, im Mittelpunkt. Oft lautet die Struktur: „Als [Nutzer/Akteur] möchte ich [Funktion], damit [Nutzen].“ Dieses einfache, wirkungsvolle Format beschreibt, wer die Funktion nutzt, was gewünscht wird und warum. Damit bietet es eine umfassende Gesamtsicht der Anforderung.

Angenommen, die Nutzer eines Onlineshops benötigen eine bessere Suche. Die passende Story könnte lauten: „Als Käufer möchte ich eine effizientere Suchfunktion, damit ich interessante Produkte schnell finde.“ Das beschreibt die Funktion kurz aus Nutzersicht und macht ihren Wert deutlich.

User Stories dienen außerdem als Ausgangspunkt für ausführliche Gespräche zwischen Stakeholdern, Product Ownern und Entwicklungsteams. Sie eröffnen sinnvolle Diskussionen über Kundenbedürfnisse und fördern Zusammenarbeit und Verständnis.

Darüber hinaus unterstützen sie die Priorisierung im Product Backlog. Sie helfen zu bestimmen, welche Funktionen für Endnutzer besonders wichtig sind und zuerst entwickelt werden sollten.

Die Rolle von User Stories im agilen Projektmanagement

User Stories zu verstehen hilft Projektteams erheblich, Kundenbedürfnisse klar zu erkennen. So können sie außergewöhnlichen Nutzen liefern, indem sie sich auf die Funktionen konzentrieren, die Endnutzern wirklich wichtig sind.

Es ist wie beim Hausbau: Ohne Bauplan und Verständnis der Wünsche des Eigentümers würden Sie nicht beginnen. Ebenso bilden User Stories die Grundlage und begleiten das Entwicklungsteam durch das Projekt, indem sie alle Anstrengungen auf die Kundenerwartungen ausrichten.

Angesichts ihrer Bedeutung in agilen Umfeldern sollten Organisationen die Schulung ihrer Teams in wirksamen User Stories priorisieren. Das International Scrum Institute bietet umfassende Ressourcen zu diesem grundlegenden Aspekt agiler Methoden. Sie erläutern die Formulierung verfeinerter Stories und bewährte Praktiken ihrer Verwaltung im Product Backlog.

Nachdem die Bedeutung von User Stories im agilen Projektmanagement klar ist, betrachten wir nun die Erstellung wirksamer, wirkungsvoller Stories.

Scrum User Stories wirksam erstellen

User Stories stehen im Mittelpunkt agiler Entwicklung. Ihre gute Formulierung ist entscheidend für den Projekterfolg. Beachten Sie dazu folgende wesentliche Prinzipien.

Nutzerbedürfnisse verstehen

Der erste entscheidende Schritt ist das Verständnis der Schwierigkeiten und Bedürfnisse der Endnutzer. Nehmen Sie sich Zeit, sich in ihre Erfahrungen, Wünsche und Herausforderungen hineinzuversetzen. So sprechen Ihre Stories echte Bedürfnisse an und liefern greifbaren Nutzen. Befragungen, Interviews und Beobachtungsstudien liefern Erkenntnisse direkt von den Nutzern.

Stories strukturieren

SMART bietet eine hilfreiche Perspektive für Gespräche über das angestrebte Ergebnis einer Story; es ist keine vorgeschriebene Scrum-Vorlage:

• Spezifisch - Festlegen, was getan werden muss
• Messbar - Bestimmen, wie Erfolg gemessen wird
• Erreichbar - Die Machbarkeit unter den gegebenen Einschränkungen sicherstellen
• Relevant - An Geschäftszielen und Nutzerbedürfnissen ausrichten
• Terminiert - Einen klaren Lieferzeitrahmen festlegen

Das schafft einen klaren Rahmen für die Entwickler und stellt sicher, dass jede Story direkt zu den Projektzielen beiträgt und echten Nutzernutzen liefert.

Das Team einbeziehen

Die Einbeziehung des gesamten Teams fördert Zusammenarbeit und ein gemeinsames Verständnis von Anforderungen und Endzielen. Entwickler, Designer, Tester und Product Owner bringen Perspektiven für ein ganzheitliches Bild ein. So werden wertvolle Erkenntnisse und mögliche Schwierigkeiten früh sichtbar und Stories verfeinert, die die gemeinsame Teamvision besser repräsentieren.

Mit Empathie für Endnutzer, wirksamer Strukturierung und Beteiligung des gesamten Teams verfügen wir nun über die Grundlagen für überzeugende, wirkungsvolle Scrum User Stories.

Auf dieser Grundlage betrachten wir Techniken zur Priorisierung und zur Maximierung ihrer Wirkung in agilen Projekten.

Techniken zur Priorisierung von User Stories

Mit wachsendem Product Backlog wird wirksame Priorisierung unerlässlich. Nicht jede Funktion ist gleich wichtig oder hat denselben Einfluss auf Kundenzufriedenheit und Produktentwicklung. Zwei starke Techniken unterstützen fundierte Entscheidungen und größtmöglichen Wert für Ihr agiles Team.

MoSCoW-Methode

MoSCoW ordnet User Stories vier Kategorien zu: Must have, Should have, Could have und Won’t have at this time. Der einfache, wirksame Ansatz identifiziert entscheidende Entwicklungsfunktionen anhand von Dringlichkeit und Bedeutung.

• Unverzichtbar (Must Have): Nicht verhandelbare Funktionen, die für den grundlegenden Betrieb oder wesentliche Nutzerbedürfnisse unerlässlich sind. Ohne sie wäre der Hauptzweck des Produkts gefährdet.
• Wichtig (Should Have): Wichtige, aber für das erste Release nicht entscheidende Funktionen. Sie vervollständigen das Produkt und können bei Bedarf verschoben werden.
• Wünschenswert (Could Have): Optionale, erwünschte Funktionen, die das Nutzererlebnis verbessern oder Wert ergänzen. Sie können ohne Beeinträchtigung der Kernfunktionalität später umgesetzt werden.
• Derzeit ausgeschlossen (Won’t Have): Aktuell als unnötig bewertete Funktionen, die bewusst außerhalb des derzeitigen Arbeitsumfangs liegen.

Diese klare Einteilung stimmt die Erwartungen von Stakeholdern und agilem Team aufeinander ab und erleichtert Einigkeit darüber, was zuerst entwickelt werden sollte.

Kano-Modell

Ergänzend zu MoSCoW ordnet das Kano-Modell User Stories nach ihrer Wirkung auf die Kundenzufriedenheit ein. Es unterscheidet Basis-, Leistungs- und Begeisterungsmerkmale.

• Basismerkmale: Grundlegende Anforderungen, die Kunden erwarten und oft als selbstverständlich ansehen. Ihre Erfüllung erhöht die Zufriedenheit nicht zwingend, ihr Fehlen kann jedoch unzufrieden machen.
• Leistungsmerkmale: Sie stehen direkt mit der Zufriedenheit in Verbindung: Je besser die Leistung, desto höher die Zufriedenheit. Dabei gilt abnehmender Zusatznutzen; übermäßige Verbesserungen erzeugen nicht immer zusätzliche Begeisterung.
• Begeisterungsmerkmale: Sie können Kunden positiv überraschen und begeistern, beeinflussen bei ihrem Fehlen die Zufriedenheit aber nur wenig.

Die Zuordnung jeder Story zu einer Kategorie gibt Product Ownern tiefere Einblicke in Nutzerprioritäten. So entscheiden sie über Funktionen passend zu Bedürfnissen und Wünschen.

Diese Priorisierungstechniken richten das Team auf wirklich wichtige Funktionen aus, vermeiden verschwendeten Aufwand für Nebensächliches und erhöhen die gesamte Kundenzufriedenheit.

Nach diesen Priorisierungstechniken betrachten wir die entscheidende Rolle der Stakeholder bei Gestaltung und Verfeinerung der Stories.

Die Rolle von Stakeholdern bei Scrum User Stories

Stakeholder sind in Scrum wie Leitsterne. Sie wissen, was Nutzer möchten und das Unternehmen benötigt. Ihre Beiträge sind wesentlich, damit Stories die Anforderungen und Erwartungen beider Seiten widerspiegeln. Ohne ihre Beteiligung wäre es wie Autofahren ohne Karte: ohne Richtung und mit hohem Risiko, sich zu verirren.

Stellen Sie sich eine neue mobile Banking-App vor. Stakeholder vertreten Marketing, Kundenservice, IT-Sicherheit und verschiedene Technologieabteilungen. Ihre unterschiedlichen Perspektiven ergeben ein umfassendes Anforderungsbild: Marketing könnte eine ansprechende, intuitive Oberfläche betonen, der Kundenservice reibungslose Interaktionen und die IT-Sicherheit robuste Schutzprotokolle.

Wie es ein ganzes Dorf braucht, um ein Kind großzuziehen, braucht eine erfolgreiche User Story Beiträge all dieser Perspektiven.

Stakeholder am Refinement zu beteiligen hilft auf verschiedene Weise:

• Praxisnähe: Sie liefern Erkenntnisse aus realen Situationen und Nutzerbedürfnissen und richten Stories damit an praktischen Geschäftsanforderungen aus.
• Feedbackschleife: Aktive Beteiligung ermöglicht Rückmeldungen in jeder Phase und dadurch iterative Verbesserungen.
• Ausrichtung an Geschäftszielen: Stakeholder verbinden Stories mit übergeordneten Zielen und unterstützen strategischere Entscheidungen.

Ohne Stakeholder-Beiträge für unsere Banking-App könnten Funktionen entstehen, die Kundenerwartungen oder regulatorische Standards verfehlen. Daraus könnten Verzögerungen oder kostspielige Nacharbeiten entstehen.

Ihre frühe Einbindung fördert außerdem Eigenverantwortung und ein Umfeld starker Zusammenarbeit und Kommunikation.

Ihre Beteiligung am Refinement von Scrum User Stories ist daher entscheidend. Erkenntnisse und Orientierung richten Stories auf Geschäftsziele und eine wirksame Erfüllung von Nutzerbedürfnissen aus.

Nach dieser unverzichtbaren Rolle betrachten wir die Schätzung von Komplexität für wirksames Scrum-Management. (Mehr über Scrum-Aufwandsschätzung)

Komplexitätsschätzung für wirksames Scrum-Management

Die Größenbestimmung einer User Story hilft, Aufwand und Komplexität zu verstehen. Schätzungen unterstützen Entscheidungen, sind aber keine Garantien. Scrum schreibt keine bestimmte Technik vor. Eine besonders beliebte Methode ist Planning Poker mit Kartenwerten für unterschiedliche Aufwands- oder Komplexitätsstufen.

Das Team bespricht eine Story und wählt anschließend einzeln eine Schätzkarte. Die Karten werden gleichzeitig aufgedeckt und wesentliche Unterschiede diskutiert. Das geht so lange weiter, bis ein Konsens über die Komplexität erreicht ist.

So wird jede Meinung berücksichtigt und aktive Teilnahme gefördert. Gemeinsame Schätzungen vertiefen das Verständnis der verschiedenen Perspektiven und können bisher unbemerkte Schwierigkeiten oder Komplexität aufdecken.

Nehmen wir eine Story zur Erstellung einer Anmeldeseite. Ein Mitglied hält sie für einfach und schlägt 3 vor, ein anderes berücksichtigt verschiedene Validierungsregeln und nennt 8. Offene Diskussion vertieft das Aufgabenverständnis und macht möglicherweise übersehene Bestandteile sichtbar.

Planning-Poker-Schätzungen helfen nicht nur beim Sprint Planning, sondern auch bei Ressourcenzuordnung und Kapazitätsverständnis. Der Product Owner nutzt sie zur Priorisierung von Stories nach Komplexität und möglichem Nutzen.

Diese Schätzungen bestimmen, wie viel Arbeit im Sprint realistisch ist, und verhindern überzogene Zusagen mit Überlastung oder Qualitätsproblemen. Sie zeigen zudem Story-Abhängigkeiten und unterstützen bessere Reihenfolge und Koordination.

Wirksame Komplexitätsschätzung, etwa durch Planning Poker, ist grundlegend für Transparenz, Zusammenarbeit und fundierte Entscheidungen im Scrum-Projektmanagement.

Nachdem wir diesen Einfluss verstehen, betrachten wir die Nutzung von User Stories für wirksames Product-Backlog-Management.

Scrum User Stories für das Product-Backlog-Management nutzen

User Stories vertreten die Kundenstimme und geben Entwicklern Orientierung für Produkte nach Endnutzerbedürfnissen. Ihr Kontext klärt Erwartungen und Nutzen. Wirksam eingesetzt schaffen sie klare Kommunikation und einfachere Entscheidungen durch ein umfassendes Anforderungsverständnis – eine Grundlage für ein gut organisiertes, verfeinertes Product Backlog.

Kunden, Endnutzer, Product Owner und Entwickler sollten an der Formulierung beteiligt werden. Ihre unterschiedlichen Sichtweisen erfassen vielfältige Anforderungen und Anwendungsfälle und ermöglichen ein ganzheitlicheres Bild der Funktionen.

Bei einer Banking-Anwendung könnte eine Story den Wunsch nach einfachen Überweisungen zwischen Konten beschreiben. Sie vermittelt die konkrete Funktionalität und ihren möglichen Einfluss auf das Nutzererlebnis.

User Stories sind dynamisch und lassen sich mit neuen Kundenbedürfnissen und Markttrends weiter verfeinern und priorisieren. Ihre regelmäßige Aktualisierung hält das Product Backlog agil und an veränderte Geschäftsanforderungen anpassbar.

Jede Story muss ihre Funktion klar und konkret beschreiben. Ein gängiges Format lautet: „Als (Rolle) möchte ich (Funktion), damit (Nutzen).“

Akzeptanzkriterien ergänzen klare Bedingungen dafür, wann eine Funktion als abgeschlossen gilt. Sie messen objektiv, ob sie ihren Zweck erfüllt, und richten Entwickler und Stakeholder auf die erwarteten Ergebnisse aus.

Für die Überweisung könnte ein Kriterium festlegen, dass Kontozugangsdaten validiert und Transaktionsbelege unverzüglich erzeugt werden. So verstehen alle Beteiligten gemeinsam, was eine erfolgreiche Umsetzung dieser Story ausmacht.

Die wirksame Nutzung von Stories hilft Product Ownern, Anforderungen zu präzisieren, und Entwicklern, passende Lösungen zu gestalten. Ständige Verfeinerung angesichts veränderter Geschäftsumfelder schafft ein anpassungsfähiges Backlog für dynamische Marktbedürfnisse.

Die Vielseitigkeit von Scrum User Stories hält das Product Backlog reaktionsfähig gegenüber wechselnden Kundenbedürfnissen und Marktdynamiken. Diese Anpassungsfähigkeit ist wesentlich für Produkte, die Endnutzern wirklich entsprechen.

Was sind die wesentlichen Bestandteile einer Scrum User Story?

Antwort: Rolle oder Persona, eine kurze Beschreibung der gewünschten Funktion und Akzeptanzkriterien. Sie vermitteln die Endnutzerperspektive und geben der Entwicklung klare Orientierung. In einer Stack-Overflow-Befragung von 2023 betonten 87% der agilen Teams die Bedeutung klar definierter Stories für wirksames Backlog-Management.

Wie unterstützt eine User Story Sprint Planning und Priorisierung in Scrum?

Antwort: User Stories machen Nutzerperspektive, Bedürfnisse und gewünschte Ergebnisse klar. Das Entwicklungsteam richtet seine Arbeit daran aus und bestimmt anhand von Wert und Komplexität, welche Stories zuerst umgesetzt werden. Laut einer VersionOne-Befragung von 2022 erzielen Teams mit wirksamer Story-Priorisierung beim Sprint Planning höhere Produktivität und Kundenzufriedenheit.

Welchen Zweck hat eine User Story in Scrum?

Antwort: Sie erfasst Anforderungen und Bedürfnisse von Endnutzern oder Kunden. Als Kommunikationsmittel zwischen Entwicklungsteam und Stakeholdern verbessert sie Verständnis und Zusammenarbeit. Sie konzentriert sich auf Kundennutzen und unterstützt Backlog-Priorisierung anhand von Feedback und Geschäftswert. In einer Scrum-Alliance-Befragung bestätigten 76%, dass User Stories die Fähigkeit ihres Teams zur Kundennutzen-Lieferung verbessert hätten.

Wie schreibt man wirksame User Stories für agile Entwicklung?

Antwort: Orientieren Sie sich an den „drei C“: Card für eine kurze Beschreibung, Conversation für die Detaildiskussion und Confirmation für Akzeptanzkriterien. Halten Sie Stories kurz, konkret und nach Kundennutzen priorisiert. Laut VersionOne sahen 65% der agilen Teams kleine, klar definierte Stories als Beitrag zum Projekterfolg. Regelmäßige Zusammenarbeit von Entwicklern, Product Ownern und Kunden sichert außerdem gemeinsames Verständnis und Anforderungsabstimmung.

Welche bewährten Praktiken und häufigen Fallstricke gibt es bei User Stories in Scrum?

Antwort: Definieren Sie Rolle, Ziel und Nutzen klar, priorisieren Sie nach Wert und Komplexität, beziehen Sie das gesamte Team in Formulierung und Schätzung ein und verfeinern Sie das Backlog regelmäßig. Häufige Fehler sind übermäßig detaillierte oder technische Stories, fehlende Stakeholder-Beteiligung, nicht aufgeteilte große Stories und seltene Backlog-Aktualisierung. Laut einer Scrum-Alliance-Befragung berichteten Teams mit diesen Praktiken von besserer Kommunikation (74% der Befragten), besserer Ausrichtung an Geschäftszielen (68%) und höherer Kundenzufriedenheit (62%).

Zusammenfassung zu Scrum User Stories

Ein wesentlicher Aspekt ist die sorgfältige Zuordnung der Anforderungen. Jede User Story ist Teil iterativer Entwicklung und beschreibt bedeutsame Arbeit für das Team. Als Bausteine von Epics tragen sie zum Iterationserfolg bei. Epics aus mehreren Stories zu identifizieren unterstützt eine umfassende Planung und Umsetzung. Dieser Artikel zeigte, wie User Stories Kommunikation im Unternehmen und die Vermittlung wertvoller Informationen verbessern.

Sie bieten greifbare Vorteile für Entwickler und Endnutzer. Die Beispiele des Artikels zeigen, wie User Stories wirksame Teststrategien unterstützen, damit Lieferergebnisse festgelegte Kriterien erfüllen. Die Zerlegung komplexer Funktionen erleichtert iterative Entwicklung. Das fördert Zusammenarbeit und Anpassungsfähigkeit bei veränderten Anforderungen während jeder Iteration.

User Stories sind somit ein zentraler Bestandteil agiler Ansätze und bieten strukturiertes Projektmanagement. Ob Epics zerlegt, Iterationen effizient geplant oder Kommunikation verbessert werden: Sie tragen entscheidend zu erfolgreichen Ergebnissen bei. Die Beispiele und Diskussionen zu Teststrategien zeigen ihren Wert, indem jedes Lieferergebnis mit den Gesamtzielen übereinstimmt. Wer agile Methoden vertiefen möchte, kann beim International Scrum Institute eine Scrum-Zertifizierung erwerben und Fachkenntnis und Sicherheit für dynamisches Projektmanagement ausbauen.