Scrum Guide | 19. User Stories – was sind sie?

Die User Story ist eine kurze Beschreibung einer neuen Produktfunktionalität oder deren Verbesserung. Sie enthält keine technische Lösung, sondern beantwortet Fragen zur Funktionalität: Wer ist der Benutzer? Was macht das Produkt? Und was ist sein Zweck? Die User Story beschreibt das Produkt in Alltags- oder Geschäftssprache, weist jedoch auch auf die Aufgaben des Scrum-Teams hin, die darauf abzielen, die Leistung des Teams zu verbessern.

Was sind User Stories? – Inhaltsverzeichnis:

1. Einführung
2. User Story. Wessen Geschichte ist es?
3. Wie verwendet man User Stories?
4. Akzeptanzkriterien
5. Zusammenfassung

Einführung

User Story ist die gebräuchlichste Art und Weise, die Aufgaben des Scrum-Teams zu formulieren. Eine einzelne User Story definiert eine kleine Funktionalität des Produkts. Sie beschreibt das kleinste sinnvolle, partielle Produktziel. Aus diesem Grund sind User Stories sehr kurz.

User Stories werden während der gesamten Zeit der Arbeit am Produkt erstellt. Sie werden kontinuierlich erstellt, vom Moment der Entscheidung, mit der Arbeit zu beginnen, bis zur Realisierung des Produktziels.

Die Erstellung von User Stories ist eine Aufgabe des Product Owners. Basierend auf einem Gespräch mit einem Kunden formuliert er Antworten auf Fragen, die es ermöglichen, eine User Story zu erstellen und sie in das Product Backlog einzutragen. User Stories spiegeln jedoch nicht nur die Bedürfnisse der Kunden wider.

User Story. Wessen Geschichte ist es?

Das Scrum-Team erstellt eine User Story, um die Bedürfnisse des Benutzers zu definieren, und deshalb wird sie in Geschäftssprache verfasst. Mit anderen Worten, sie zeigt die Vorteile an, die ihre Umsetzung dem Produktbenutzer bringen wird. Im Product Backlog kann es jedoch auch User Stories geben, die die Bedürfnisse des Entwicklungsteams beschreiben, zum Beispiel die Verbesserung des Workflows zwischen Entwicklern, oder die Bedürfnisse des Product Owners, zum Beispiel die Organisation des Product Backlogs. In solchen Fällen ist der Benutzer in der User Story der Entwickler und der Product Owner.

Eine User Story kann beschrieben werden, indem man die 3W-Fragen beantwortet:

• Wer?
• macht Was?
• Warum?

Die User Story wird dann in einer Formel zusammengefasst:

Als [Benutzertyp], möchte ich [was tun?] Weil [warum?].

Beispiele für User Stories über die Funktionalität eines Online-Shops, die in dieser Form verfasst sind, sind in der Tabelle unten dargestellt:

Diese Formel ermöglicht es nicht nur, eine User Story zu formulieren, sondern auch, technische Sprache relativ einfach in Geschäftssprache und umgekehrt zu übersetzen. Infolgedessen sehen sowohl Entwickler als auch Stakeholder klar das Ziel und die Phasen seines Fortschritts. Wir werden auch die Erstellung guter User Stories mit der INVEST-Methode in einem separaten Artikel in der Scrum Guide-Serie behandeln.

Wie verwendet man User Stories?

Die Erstellung einer schematischen User Story ist nur der Anfang. Sie sind Signale und Ausgangspunkt für Diskussionen über Probleme und deren Lösungen. Die Diskussion über User Stories findet während der Sprint-Planung statt, um zu klären, welche technischen Probleme das Entwicklungsteam in das Sprint-Backlog aufnehmen wird.

Typischerweise werden User Stories im physischen Raum auf kleinen, bunten Karten geschrieben, die am Arbeitsplatz befestigt sind. Im digitalen Raum funktionieren digitale Whiteboards, die vom Scrum-Team geteilt werden, am besten.

Die Speicherung von User Stories auf diese Weise hat mehrere Vorteile, weil:

• Die Autonomie jeder User Story betont – jede hat einen separaten Rahmen und kann unabhängig von den anderen ausgeführt werden
• Die Dynamik der User Stories betont – die Reihenfolge ihrer Realisierung wird vom Scrum-Team neu verhandelt, und die aktuelle Reihenfolge der Realisierung ist dank der physischen Anordnung der Karten mit User Stories auf dem Board sichtbar
• Als Erinnerung dient – dank der visuellen Darstellung der User Stories hat das Scrum-Team einen Wegweiser im Blick, um sich beim Erstellen detaillierter Lösungen an das Ziel zu erinnern.

Das Entwicklungsteam schätzt den erforderlichen Aufwand zur Fertigstellung einer User Story in Tagen, Mannstunden oder Story Points.

Akzeptanzkriterien

Eine User Story muss bestimmte Akzeptanzkriterien im Moment ihrer Annahme zur Entwicklung durch das Entwicklungsteam haben. Die Akzeptanzkriterien bestimmen, zu welchem Zeitpunkt die Arbeit an einer User Story als abgeschlossen betrachtet werden kann.

Auf diese Weise wissen sowohl der Kunde als auch die Entwickler, wie ihre Arbeit in Geschäftswert übersetzt wird. Typischerweise wird eine User Story als abgeschlossen betrachtet, wenn der darin angegebene Benutzer die beschriebene Aktion ausführen kann. Anhand des obigen Beispiels werfen wir einen Blick auf diese User Story mit dem Inhalt:

Ein Kunde kann mit einem einzigen Klick einen Zauberstab kaufen.

Sie ist abgeschlossen, wenn ein funktionierender “Jetzt kaufen”-Button auf der Seite des Online-Shops erscheint, der die standardmäßigen Zahlungs- und Versandinformationen für den angemeldeten Benutzer verwendet.

Zusammenfassung

Eine User Story ist eine prägnante Beschreibung einer neuen Produktfunktionalität oder -verbesserung. Sie dient als das kleinste Ziel, das in Geschäftssprache ausgedrückt wird, das heißt, aus der Perspektive des Geschäftswerts und des Benutzers. Sie hilft, die auszuführende Aufgabe sowie die Kriterien für deren Abschluss klar zu definieren.

Wenn Ihnen unsere Inhalte gefallen, treten Sie unserer aktiven Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.