Der Begriff „User Story“ bedeutet wörtlich übersetzt Anwender- oder Benutzergeschichte. In Scrum wird die User Story als Werkzeug genutzt, um die gewünschten Funktionen eines Produkts aus Sicht des Benutzers zu beschreiben. Eine gute User Story ist für das Team leicht zu verstehen und dient so dazu, die Wünsche der Anwender an die Developer zu vermitteln. User Stories erleichtern auch die Schätzung des Aufwands.
User Stories für den Überblick
Jede einzelne User Story wird auf eine eigene Karte oder PostIt geschrieben, mit dem Ziel einen Überblick zu erlangen, welche Aufgaben zu erledigen sind. Auch die Festlegung der Reihenfolge und die Schätzung des zeitlichen Aufwands kann so erfolgen.
Product Owner hat die Verantwortung
Auch wenn die Verantwortung für die Backlog Pflege und die Sprintplanung beim Product Owner liegt – das Schreiben einer User Story kann jedes Mitglied im Team übernehmen. Wichtig ist, dass jede Story im Team diskutiert wird.
Welche Templates gibt es für gute User Stories?
Die User Story wird aus Sicht des Benutzers erstellt. Als hilfreich für die Erstellung, hat sich die Beantwortung der drei Fragen “Wer? Was? und Warum? erwiesen. So könnte dann ein Scrum User Story Beispiel aussehen:
Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.
Template zur Formulierung einer User Story
Bzw. „als Anwender möchte ich Funktion um Nutzen“. Bei der Formulierung sollte die User Story möglichst kurz und mit einfachen Worten beschrieben werden. So wird sichergestellt, dass jeder im Team schnell versteht worum es geht.
Die Struktur aus dem oben genannten Scrum User Story Beispiel, dient auch dazu zu definieren, wann die Aufgabe erledigt ist. Nämlich dann, wenn der in der User Story genannte Benutzer in der Lage ist den beschriebenen Task auszuführen.
Die drei Cs einer User Story
Als wichtige Grundregeln bei der Entwicklung von User Stories gelten die drei Cs:CCC (Card, Conversion, Confirmation).
Card: User Stories werden auf Karten geschrieben. Ob diese aus Papier oder in einem Tool bestehen, ist dabei zweitrangig. Wichtig ist: der Platz auf der Karte sollte ausreichen, um das Ziel der User Story zu vermitteln. Die Formulierung sollte kurz und prägnant sein.
Conversation: über jede User Story wird im Team gesprochen. Hier werden Details jeder Story besprochen, die über die Formulierung auf der Karte hinausgehen. Diese Diskussionen finden während der Sprint Planungsmeetings statt.
Confirmation: vor Beginn der Umsetzung einer Story werden verbindliche Akzeptanzkriterien definiert. Anhand dieser lässt sich dann nachweisen, dass alle Stories in der gewünschten Form umgesetzt worden sind.
Gute User Stories durch INVEST
Wie stellt man nun fest ob User Story qualitativ gut ist? Dabei hilft uns das INVEST-Prinzip. Das Akronym steht für folgende Kriterien:
Independent
Die User Story ist frei und unabhängig von anderen. So könnten sie sogar aus dem Product Backlog heraus genommen werden können, ohne das übrige Product Backlog groß zu beeinflussen.
Negotiable
User Stories sollten keine Lösungen vorgeben und Raum für Diskussionen zwischen Scrum Developer und Kunde lassen.
Valuable
Eine User User stellt für sich einen Wert dar. Wird die User User Story umgesetzt, so wird eine Wertsteigerung im zu entwickelnden Produkt erzielt.
Estimatable
Nur wenn eine User Story durch das Scrum Developer Team geschätzt worden ist, kann es in das Spirnt Backlog aufgenommen werden.
Sized appropiately
Eine User Story sollte genau so groß sein, dass sie im Rahmen eines Sprints umgesetzt werden kann.
Testable
Jede User User Story sollte für sich testbar sein. Dazu werden Acceptence Criteria / Akzeptanzkriterien definiert, die durch die Scrum Developer und dem Product Owner auf ihre Einhaltung hin überprüft werden.
Das könnte Dich auch interessieren:
