Zum Inhalt

Theorie "User Stories, Epics, Product Backlog Items"

Sie haben die ersten beiden Kapitel schon erfolgreich bearbeitet und damit können Sie theoretisch schon Ihr erstes Scrum-Projekt starten. Denn es müssen genau zwei Dinge erfüllt sein: Das Scrum Team muss aufgestellt sein und das Product Backlog muss existieren. Wie Sie aus dem vorherigen Kapitel wissen, ist das Product Backlog eine Auflistung aller Eigenschaften, über die ein Produkt verfügen soll. Die Auflistung erfolgt mittels User Stories oder Product Backlog Items.

Einträge im Product Backlog

Alle Einträge, die sich im Product Backlog befinden werden Product Backlog Items genannt. Dies können Themes, Epics oder User Stories sein. Das heißt, dass jede User Story ein Product Backlog Item ist, aber nicht jedes Product Backlog Item ist eine User Story. Und um Ihnen noch einmal den Unterschied zwischen User Stories, Epics und Themes ins Gedächtnis zu rufen:

User Stories sind Wünsche und Anforderungen an ein Endprodukt, Epics sind sehr umfangreiche User Stories und Themes sind mehrere User Stories, die zu einem gemeinsamen Themenbereich zusammengefasst sind.

In diesem Kapitel werden Sie erfahren, wie User Stories formuliert sein müssen, dass sie weiterbearbeitet werden können.

User Stories

Ein wichtiges Kriterium bei der Erstellung und Gestaltung des Product Backlog ist die Sichtweise des Kunden oder Endnutzers des Produktes. User Stories geben dem Nutzer, also dem Anwender, die Möglichkeit in seiner Sprache auszudrücken, was er sich wünscht. Daher werden die Einträge in Form von User Stories erstellt und in den Product Backlog eingetragen. Mittlerweile wird weitestgehend darauf verzichtet, die technische Umsetzung der Anforderungen in den Product Backlog zu übernehmen. Technische Aspekte und Fragen der Umsetzung werden im Sprint Backlog ausformuliert. Dadurch ist sichergestellt, dass jeder Teilnehmer am Projekt - etwa Kunden, Endnutzer oder auch andere Stakeholder - seine Wünsche ausdrücken können, ohne technische Kenntnisse zu besitzen oder sich fachlich ausdrücken zu müssen.

Kurz gesagt

User Stories helfen den Developern zu verstehen, was sich Endnutzer wünschen und Endnutzer können unkompliziert ihre Wünsche mitteilen, ohne über technisches Know-how verfügen zu müssen. Auf diese Art und Weisen wird ein gemeinsames Verständnis geschaffen.

Eine User Story wird aus der Sicht des Anwenders geschildert und beinhaltet Informationen bezüglich „Rolle" (wer?), „Funktionalität" (was?) und „Geschäftswertbeitrag" (warum?), also worin der Nutzen oder Mehrwert besteht. Es ist jedoch nicht zwingend notwendig, dass der Anwender die User Story schreibt. Dies kann der Product Owner stellvertretend für den Kunden übernehmen oder User Stories gemeinsam mit den Developern ausformulieren.

Wenn eine User Story formuliert wird, sollte folgender Satz um die Rolle die der Nutzer einnimmt, die Funktionalität die von der User Story erwartet wird und den Geschäftswertbeitrag ergänzt werden:

Als ... möchte ich ..., so dass ...

Zum Beispiel könnte der Satz folgedermaßen vollendet werden:

Als angehender Scrum Master möchte ich Übungsaufgaben zur Verfügung gestellt bekommen, sodass ich die Zertifizierungsprüfung meistern kann.

Abb. 3.1: Ein User-Story-Kärtchen.

Ausgestaltung von User Stories - die drei Cs

Das Erstellen von User Stories beinhaltet aber noch mehr als die Ergänzung eines Satzes um „Rolle", „Funktion" und „Geschäftswertbeitrag".

Wie Sie am Bild weiter oben erkennen, wird eine User Story auf eine Karte geschrieben - meist physisch, jedoch ist es auch möglich digitale Karten für die Ausformulierung von User Stories zu nutzen. Sobald die User Story niedergeschrieben wurde, sollte über sie gesprochen werden - dies geschieht spätestens, wenn der Aufwand geschätzt wird. Und letztendlich gilt zu beachten, dass eine User Story am Ende eines Sprints abgenommen werden muss - dies geschieht anhand vorher definierter Akzeptanzkriterien.

Sie müssen also bei der Erstellung die drei Cs - card, conversation und confirmation, im Hinterkopf behalten:

Abb. 3.2: Die drei Cs bildlich dargestellt.

Card: Die wichtigsten Daten einer User Story werden auf einer Karte festgehalten. Dazu gehören die Priorität der User Story, ihre Akzeptanzkriterien und auch der Arbeitsaufwand für die Umsetzung einer User Story, der in einer Schätzklausur ermittelt wurde. Da eine Karte nur begrenzt Platz bietet, muss die User Story auf den Punkt gebracht werden.

Conversation: Aus einer User Story, die kurz und knapp formuliert ist, sollte sich ein Gespräch zwischen Product Owner und den Developern ergeben. Diese sollen sich ausführlich über die User Story austauschen und jeder soll das Ziel der User Story verstehen.

Confirmation: Aus dem Gespräch zwischen Product Owner und Developer müssen sich Akzeptanzkriterien (acceptance criteria) ergeben, welche festgehalten werden. Der Product Owner nimmt die Umsetzung der User Story als Increment durch entsprechenden Akzeptanztests ab.

Definition of Ready (DoR)

Es ist wichtig, immer eine ausreichende Anzahl von User Stories im Zustand „Ready" zu haben. Der Status „Definition of Ready" (DoR) bedeutet, dass ganz oben im Product Backlog gelistete User Stories so formuliert sein müssen, dass diese für die Developer verständlich sind und beim nächsten Sprint bearbeitet werden können. Wie Sie weiter oben gelesen haben, ist es relevant, dass sich Prodcut Owner und Developer über User Stories austauschen und dass User Stories verstanden werden, bevor mit der Umsetzung begonnen wird.

Anders ausgedrückt: Erst wenn die Developer sagen, dass sie eine anstehende Aufgabe verstanden haben, kann sie als „ready" betrachtet werden. Die PBIs müssen der DoR und den drei Cs entsprechen, erst dann sind diese für das Sprint Backlog bereit und können bearbeitet werden. Für eine Umsetzung in Aufgaben (Tasks) müssen Sie hinreichend klein und detailliert sein. Damit können sie jederzeit in das Sprint Planning übernommen und in Folge dem Sprint zugeführt werden.

Wenn Product Backlog Items nicht der DoR entsprechen und die Entwickler diese auch nicht exakt verstanden haben, kann der Entwicklungsaufwand steigen und die Bearbeitung der Items den zeitlichen Rahmen des Sprints sprengen. Dies führt im schlimmsten Fall dazu, dass das Sprint Goal verfehlt oder ein Increment nicht rechtzeitig geliefert wird.

Um zu überprüfen, ob Ihre User Stories der Definition of Ready entsprechen gibt es unterschiedliche Kriterien, die zu Rate gezogen werden können:

Die INVEST-Kriterien

Um eine User Story umsetzbar zu machen, sollte sie unabhängig (independent) sein, sodass sie separat und nicht im Zusammenhang mit anderen User Stories bearbeitet und priorisiert werden kann. Der Vorteil, der sich hieraus ergibt ist, dass es keinen Einfluss auf andere User Stories hat, wenn sie bearbeitet wird.

User Stories sollten zwar detailliert genug sein, dass die Developer und andere Beteiligte eine Idee haben, was sich dahinter verbirgt, es sollte aber noch genug Spielraum für Diskussionen geben. Falls die Diskussionen zu Anpassungen führen sollten, sollte die User Story verhandelbar (negotioable) sein.

Wie Sie bereits aus dem vorherigen Kapitel wissen, ist das höchste Ziel der Developer, dass in jedem Sprint ein werthaltiges Increment erzeugt wird. Und um das zu erreichen ist es notwendig, dass die User Stories wertvoll (valuable) sind, sodass keine Eigenschaften umgesetzt werden, die letztendlich unnötig sind und die Developer ihrem Ziel nicht näherbringen.

Des Weiteren muss eine User Story abschätzbar (estimable) sein. Dies ist wichtig, um eine User Story vom Product Backlog in den Sprint Backlog zu überführen - denn bevor eine User Story vom Product Backlog in den Sprint Backlog „wandert" muss sie von den Developern geschätzt werden.

Auch die Größe einer User Story spielt eine Rolle. Sie sollte klein (small) genug sein, dass sie innerhalb einer Iteration, d. h. innerhalb eines Sprints umgesetzt werden kann.

Außerdem ist es wichtig, dass die Developer die umgesetzte User Story am Ende eines Sprints testen können. Die User Story muss demnach testbar (testable) sein. Die Testung geschieht anhand vorher festgelegter Akzeptanzkriterien.

INVEST - Das Akronym als Merkhilfe

Ein Akronym, welches Ihnen hilft, sich die Kriterien besser zu merken, welchen eine User Story genügen sollte, ist INVEST:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Abb. 3.3: Die INVEST-Kriterien.

DIE CTF-Kriterien

Ähnlich wie die INVEST-Kriterien sind auch die CTF-Kriterien. Eine User Story muss klar verständlich (clear), testbar (testable) und machbar (feasible) sein.

„Klarheit" wird dadurch erreicht, dass User Storys gemeinsam verfasst und mit Akzeptanzkriterien versehen werden. Hier ist der Übergang zu „testbar" fließend. Eine User Story sollte etwa über drei bis fünf Akzeptanzkriterien verfügen, sodass am Ende des Sprints beurteilt werden kann, ob das entsprechende Increment funktioniert. „Machbar" ist eine User Story, wenn sie innerhalb eines Sprints umgesetzt werden kann, dieser Punkt ist also sehr ähnlich wie „small", den Sie bereits von den INVEST-Kriterien kennen.

Achtung!

Selbst wenn eine User Story den INVEST- oder CTF-Kriterien genügt, ist dies kein Garant dafür, dass die User Story im kommenden Sprint auch erfolgreich umgesetzt wird. Wenn die User Story nicht der Definition of Ready (DoR) entspricht und die Developer erst während der Bearbeitung merken, dass sie die User Stories nicht verstehen, kann sich dies negativ auf die Umsetzung auswirken. Eine Umsetzung sollte entsprechend erst erfolgen, wenn die Developer ausdrücklich gesagt haben, dass sie ausdrücklich verstanden haben, worum es sich bei der User Story handelt.

Story Points und Agiles Schätzen

Eine wichtige Grundlage für jede weitere Planung ist das Abschätzen des Arbeitsaufwandes, der sich hinter den einzelnen Einträgen im Product Backlog verbirgt. Damit lässt sich ein erster Eindruck vermitteln, welchen Umfang die Arbeiten im Projektverlauf haben könnten.

Dabei wird darauf verzichtet, konkrete Vorhersagen zu machen, wie hoch beispielsweise etwa der Aufwand in Arbeitsstunden sein könnte. Vielmehr geht es darum, relative Größen zu ermitteln, das heißt, die Komplexität der einzelnen Einträge wird im Verhältnis zueinander geschätzt. Durch die relativen Aufwandsgrößen ist es einfacher, die Release-Pläne an geänderte Randbedingungen, die die Velocity (Entwicklungsgeschwindigkeit) verändern, anzupassen, und die Auswirkungen der Veränderungen zu bewerten. Der Fokus wird, statt auf genaue Zahlen auf eine gewollte Ungenauigkeit und damit auf nicht lineare Zahlenskalen gesetzt. Zusätzlich wird die Abschätzung „aus dem Bauch" heraus vorgenommen.

Ablauf der Schätzklausur

Die Schätzklausur erfolgt im Team zum Beispiel in Form eines „Planning Poker". Dadurch, dass das ganze Team an der Schätzklausur teilnimmt und so jeder Developer seine Erfahrungen mit in die Schätzung und die Diskussion einbringen kann, sind solche Schätzungen meist genauer, als andere.

  • Jeder Eintrag des Product Backlogs wird abgeschätzt. Man beginnt mit der User Story, die den geringsten Arbeitsumfang erwarten lässt.
  • Anschließend werden alle weiteren Einträge mit dem ersten Eintrag verglichen und relativ dazu bewertet.
  • Der Aufwand wird üblicherweise in Story Points geschätzt.

Was sind Story Points?

Story Points stellen den gefühlten Arbeitsaufwand dar und spiegeln die Wertigkeit einer User Story wider. Beeinflusst werden können Story Points bspw. durch Unsicherheiten, durch die Menge und die Komplexität der Arbeit. Sie sind weder monetär noch zeitbasiert, sondern sie stellen selbst die Maßeinheit dar, um die Product Backlog Items schätzen zu können.

Für die Story-Points-Abschätzung empfiehlt sich die Skala nach Fibonacci: Die Zahlenfolge von Fibonacci ergibt sich, wenn die vorausgehende Zahl jeweils zur nachfolgenden Zahl addiert wird (1,2,3,5,8,13,21,34). Einträge am oberen Ende der Skala haben bereits den Charakter von Epics und müssen im weiteren Verlauf in User Stories geteilt werden.

Abb. 3.4: Darstellung einer Fibonacci-Folge.

Eine weitere Möglichkeit neben den Story Points besteht darin, die Einträge mit Kleidergrößen zu vergleichen. Diese lauten: XXS, XS, S, M, L, XL und XXL. Einträge am unteren Ende der Skala haben bereits den Charakter von Epics und müssen im weiteren Verlauf geteilt werden.

Die Story Points werden im Team diskutiert. Die Developer gehen gemeinsam mit dem Product Owner durch alle Einträge des Product Backlog und es werden etwaige offenen Fragen geklärt. Im Anschluss treffen die Developer eine Abschätzung. Das letzte Wort bei der Abschätzung von Story Points liegt bei den Developern. Wenn es notwendig wird, die Schätzungen während des Sprints zu aktualisieren, sind die Developer ebenfalls dafür verantwortlich.

Wie Epics zu User Stories werden

Wie Sie nun wissen, werden User Stories vom Product Backlog in den Sprint Backlog überführt, um dort bearbeitet zu werden. Sie müssen entsprechend klein und machbar sein, dass sie innerhalb eines Sprints umgesetzt werden können. Da der Product Backlog von oben abgearbeitet wird und Epics zu groß und zu komplex sind, um sie innerhalb eines Sprints umgesetzt zu bekommen, sind sie weiter unten im Product Backlog angeordnet. Je mehr User Stories von oben weggenommen werden, desto weiter hoch „rutschen" die anderen User Stories und Epics. Zu gegebener Zeit sollten Epics weiter ausformuliert und aufgeteilt werden, sodass sie zu kleinen User Stories werden und den INVEST- bzw. CTF-Kriterien entsprechen, sobald sie oben im Product Backlog angekommen sind.