Scrum-Grundlagen: Der Product Owner

User Stories

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Epics und User Stories sind die Hauptwerkzeuge des Product Owners.

Transkript

In diesem Video widmen wir uns speziell dem Werkzeug des Product Owners, den "User Stories". User Stories sind die Darstellungsformen für eine Anforderung im Product Backlog. Dabei versucht eine User Story die wichtigsten Informationen in einem prägnanten Satz zusammenzufassen, damit das Entwicklungsteam genügend fachliche Informationen hat, um Anforderungen umsetzen zu können. Die Form einer typischen User Story ist dabei als Rolle möchte ich Ziel so dass Nutzen. Dabei ist der letzte Teil des Satzes der essentiellste, und damit wichtigste Punkt. Er beschreibt den Nutzen und damit die Daseinsberechtigung für die Anforderung. Leider wird dieser Teil der User Story viel zu oft vernachlässigt oder sogar weggelassen. Egal ob Sie in der Rolle des Scrum Masters oder Product Owners sind, achten Sie wirklich bei jeder User Story auf diesen Teil. Wenn Sie Mitglied des Entwicklungsteams sind, empfehle ich Ihnen, User Stories, die keinen verschriftlichten Nutzen haben, es gar nicht mit in den Sprint aufzunehmen. Wie für das Product Backlog gibt es auch für User Stories Kriterien, die sehr gut als Anhaltspunkte verwendet werden können, ob eine Story so genau beschrieben ist, dass sie theoretisch in ein Sprint Backlog aufgenommen werden darf. Diese Kriterien heißen INVEST-Kriterien und setzen sich aus folgenden Buchstaben und Bedeutungen zusammen: Independent (unabhängig), Negotiable (verhandelbar), Valuable (werthaltig), Estimable (schätzbar), Small (klein genug), und Testable (testbar). "Unabhängig" bezieht sich dabei, auf den Zusammenhang der User Story zu anderen User Stories. Eine User Story sollte eine in sich abgeschlossene Anforderung sein. Das heißt, dass jede User Story auch für sich selber umgesetzt werden kann, ohne auf die Beendigung einer anderen User Story zu warten oder selbst Basis für eine andere User Story zu sein. "Verhandelbar" bedeutet, dass eine Anforderung bis zu dem Zeitpunkt, wo eine User Story fix in einem Sprint Backlog aufgenommen wurde, veränderbar sein kann. Bis zu diesem Zeitpunkt können Backlog-Elemente jederzeit verändert oder umgeschrieben werden. "Werthaltig" steht im engen Zusammenhang zu dem Business Value. Eine User Story sollte dem späteren Nutzer und Anwender einen konkreten Mehrwert liefern. Dieses bedeutet automatisch, dass jede User Story den Business Value des Produktes erhöht. Dass eine User Story schätzbar ist, stellt eine zentrale Anforderung, besonders für das Entwicklungsteam dar. Der Product Owner sollte eine User Story so genau beschreiben, dass es möglich ist, die Komplexität abschätzen zu können. Nur so kann das Team beurteilen, wie viele User Stories es in einem Sprint einsetzen kann und auch nur in diesem Fall kann der Product Owner ein valides Release Management betreiben. Entscheidend für die Planung eines Sprints ist auch die Größe einer User Story Eine User Story sollte stets so klein genug sein, dass es möglich ist, sie mit einer gewissen Zuverlässigkeit in einem Sprint einzuplanen. Die letzte Anforderung, die Testbarkeit bezieht sich auf Umsetzung einer User Story. Eine User Story sollte so formuliert sein, dass es nach Umsetzung der Anforderung möglich ist, das Ergebnis zu testen. Der nächste essentielle Bestandteil einer User Story sind die Akzeptanzkriterien. Während die Formulierung einer User Story lediglich eine Kurzbeschreibung der Anforderung ist, geben die Akzeptanzkriterien ein gemeinsames Verständnis dafür, wann eine Anforderung auch umgesetzt worden ist. Dieses gemeinsame Verständnis für die Umsetzung einer Anforderung ist nicht zuletzt für das Sprint Review entscheidend, wo das Team die umgesetzte User Story vorstellt. Außerdem sind Akzeptanzkriterien, entscheidend für das Schätzen der Komplexität einer User Story. Sie geben dem Entwicklungsteam entscheidende Hinweise und Anhaltspunkte, wie hoch der Grad der Komplexität ist. Dieses bietet die Basis für eine richtige Einschätzung, wie viele Backlog Items, das Entwicklungsteam in einem Sprint, umsetzen kann. Ein Beispiel für eine User Story könnte sein "Als Besucher der Webshops möchte ich alle Suchergebnisse ordnen können, damit ich mich schnell orientieren kann". Akzeptanzkriterien können hierfür sein: Ordnung nach Preis (Ab- und Aufsteigen möglich) und Ordnung nach Kundenrezession möglich. Die User Story beschreibt in diesem Fall die Anforderung, das Ordnen von Suchergebnissen und liefert direkt den Nutzen mit. Hier die Schnelle Orientierung, der mit dieser Anforderung erfüllt wird. Akzeptanzkriterien geben einen Rahmen für die Story wieder und geben dem Team Anhaltspunkte für den Aufwand. Hier Ordnung nach zwei Kriterien.

Scrum-Grundlagen: Der Product Owner

Lernen Sie die Aufgaben des Product Owner im Scrum-Prozess kennen und profitieren Sie von den Tipps und Tricks für den Praxiseinsatz.

1 Std. 23 min (19 Videos)
Derzeit sind keine Feedbacks vorhanden...

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!