Benutzergeschichten bilden das Herzstück der agilen Entwicklung. Sie sind der wichtigste Input für das Scrum-Team. Es nimmt die User Stories und erstellt Produktinkremente, die auf der Fertigstellung dieser Stories basieren. Leider ist es gar nicht so einfach, die richtigen User Stories zu erstellen.
Weitere Informationen zu User Stories finden Sie hier:
Die Product Owner müssen lernen, wie sie User Stories erstellen können, die den Bedürfnissen des Teams entsprechen. Um gute User Stories zu erstellen, sollte man sich zunächst daran erinnern, in gute User Stories zu INVESTen. INVEST ist ein Akronym, das die folgenden Konzepte umfasst, die eine gute Benutzergeschichte ausmachen:
Independent: Ein Product Backlog Item (PBI) sollte in sich geschlossen sein.
Negotiable: Sollte Raum für Diskussionen lassen.
Wertvoll: Muss den Stakeholdern einen Wert liefern.
Abschätzbar: Der Umfang einer PBI muss immer abschätzbar sein.
Klein: Sie sollte also planbar sein, Aufgaben und Prioritäten setzen können.
Testbar: Die Entwicklung sollte testbar sein.
Stories sollten möglichst unabhängig voneinander sein und in beliebiger Reihenfolge bearbeitet werden können. Das ermöglicht eine echte Priorisierung jeder einzelnen Story. Wenn Abhängigkeiten ins Spiel kommen, kann es sein, dass es nicht möglich ist, eine wertvolle Story zu implementieren, ohne andere, viel weniger wertvolle Stories zu implementieren.
Verhandelbar
Eine gute Story ist verhandelbar und kein Vertrag. Eine gute Geschichte ist eine Einladung zu einem Gespräch. Eine gute Geschichte fängt die Essenz dessen ein, was gewünscht wird. Das tatsächliche Ergebnis muss das Resultat einer kollaborativen Verhandlung zwischen dem Product Owner und dem Entwicklungsteam sein. Das Ziel ist es, die Kundenbedürfnisse zu erfüllen.
Wertvoll
User Stories sollten im Backlog nach dem Geschäftswert priorisiert werden. Die Erstellung von Product Backlog Items, die zwar Spaß machen, aber keinen Wert für die Stakeholder bringen, verstößt gegen eines der Agilen Prinzipien, nämlich kontinuierlich wertvolle Software zu liefern
Estimable
Entwickler müssen in der Lage sein, eine Story abzuschätzen. Sie sollte so geschrieben sein, dass die Entwickler sie verstehen können und eine Vorstellung davon haben, wie sie zu implementieren ist. Schlüsselfaktoren für die Schätzung sind Fachwissen und technisches Wissen.
Klein
Gute Geschichten neigen dazu, klein zu sein, aber wie klein sollten sie sein? Die Antwort hängt vom Team und der angewandten Methodik ab. Viele Product Owner schlagen zweiwöchige Iterationen vor, die für User Stories drei oder vier durchschnittliche Arbeitstage erlauben. Dies beinhaltet die gesamte Arbeit, um die Story in einen „fertigen“ Zustand zu bringen.
Testbar
Stories sollten testbar sein, um die Vollständigkeit zu bestimmen. Eine Story sollte ein Akzeptanzkriterium haben. Die Akzeptanzkriterien sollten objektiv sein. Vermeiden Sie Kriterien wie „einfach zu bedienen“, „schnell“ oder „fehlerfrei“. Try to write criteria that can be measured and tested.
Via: