User Stories richtig schätzen? Durch Poker? Das Entwicklungsteam ist dafür verantwortlich, den Aufwand für die Implementierung von User Stories und anderen Items, an denen sie arbeiten einzuschätzen. Man kann nämlich nur eine begrenzte Menge an Arbeit in einem Sprint erledigen. Es kann sein, dass die Entwickler nicht über die erforderlichen Fähigkeiten und Erfahrungen verfügen, aber es dauert normalerweise nicht lange, bis Teams gut im Schätzen sind. User Stories müssen innerhalb eines einzigen Sprints realisierbar sein. Wenn man also in monatlichen Sprints arbeitet, muss jede Nutzergeschichte weniger als einen Monat Arbeit beschreiben. Bevorzugt man eine Solo Entwicklung, zerlegt man große Geschichten oder Epics in kleinere Geschichten, um diese Kriterien zu erfüllen. Wenn ein Team das Pair Programming übernommen hat, dann muss eine User Story eben von zwei Personen in einem einzigen Sprint umgesetzt werden können.

Schätzfaktoren als Orientierung nutzen

Wenn der Product Owner Features entwickeln lässt, möchte er wissen, wie schnell das Team die Features fertigstellen kann und wie viele Ressourcen es dazu braucht. Aus Entwicklersicht ist es unmöglich, den genauen Zeitpunkt der Fertigstellung vorherzusagen, eine Schätzung ist jedoch jederzeit möglich. Um die Schätzungen in geregelte Bahnen zu lenken kann es hilfreich sein, folgende Schätzfaktoren zu betrachten:

• Komplexität: Beziehe die Komplexität einer User Story in die Schätzung mit ein.
• Risiko: Berücksichtige die Unerfahrenheit von Teammitgliedern.
• Implementierung: Beachte technische als auch kulturelle Implementierungsfaktoren und -hindernisse.
• Einsatzbedingungen: Bedenke verschiedene Einsatzbedingungen wie Verfügbarkeit oder Kompetenzen der Teammitglieder.
• Abhängigkeiten: Betrachte externe Herausforderungen.

Story Points

Das agile Management legt Wert darauf, eine Story in Story Points statt in Stunden oder Personentagen zu schätzen. Story Points stellen eine relative Größe der User Stories dar, da der Vergleich relativer Größen einfacher ist. Story Points sind nicht an eine Einheit gebunden d.h. als Skala sind sie nur wertvoll, um sie innerhalb eines Teams miteinander zu vergleichen. Das geradezu spielerische Schätzen in Story Points ermuntert zudem alle am Schätzprozess teilzunehmen. Außerdem ist es einfach und schnell. Story Points initiieren Diskussionen auf hoher Ebene über alles, was in ein Projekt involviert ist. Mit Hilfe von Story Points vergleicht man alle User Stories miteinander.

Die abgearbeiteten Stories pro Monat ergeben automatisch eine Punktzahl. Diese verwendet man, um die Umsetzungsgeschwindigkeit eines Teams nachzuhalten, zu beschleunigen und zukünftige Arbeitsfähigkeit vorherzusagen. Für die Schätzungen verwendet man meistens die Zahlen der Fibonacci-Folge (0, 1, 2, 3, 5, 8, 13, 20, 40 und 100). Alle Teammitglieder, die für die Erstellung einer Story verantwortlich sind, sollten idealerweise Teil der Schätzung sein. Es ist hilfreich, eine Reihe ähnlicher User Stories heranzuziehen, um Vergleiche anzustellen, Empfehlungen zu geben und Prioritäten zu setzen. Zusätzlich gibt das mehr Klarheit über die Komplexität und relative Größe in Bezug auf die Entwicklung.

Planning Poker – Den Aufwand schätzen

Planning Poker wird „gespielt“ mit einer Liste der zu liefernden Funktionen (z.B. Backlog), mehreren Kopien eines Kartenspiels und optional einer Eieruhr. Diese wird verwendet, um die Diskussionszeit einzelner Items zu begrenzen. Bei der Schätzungsbesprechung erhält jeder Schätzer ein Kartendeck. Alle Decks haben identische Kartensätze. Typischerweise zeigen die Karten im Stapel die Fibonacci-Folge mit einer Null (0, 1, 2, 3, 5, 8, 13, 20, 40 und 100). Der Grund für die Verwendung der Fibonacci-Folge ist die inhärente Unsicherheit bei der Schätzung größerer Objekte. Wenn sich Teams nicht an den gleichen geografischen Standorten befinden, verwendet man eine Kollaborationssoftware als Ersatz für physische Karten verwendet.

Planning Poker Session

Ein Moderator leitet das Event, dies kann der Scrum Master sein, er spielt nicht mit. Der Product Owner präsentiert das erste Feature und erklärt, wie es zu den Zielen des Produkts beiträgt. Normalerweise würde der Product Owner jeden Artikel präsentieren, aber in Fällen, in denen Ideen von verschiedenen Personen kommen, können diese ihre eigenen Ideen auch gerne selbst vorstellen. Jede Person legt eine verdeckte Karte ab, die ihren Schätzwert für die User Story darstellt. In der Diskussion dürfen Zahlen in Bezug auf die Größe überhaupt nicht erwähnt werden, um eine Verankerung zu vermeiden. Alle Teilnehmer geben gleichzeitig ihre Schätzung preis. Wenn alle Teilnehmer die gleiche Zahl zeigen, ist die Runde beendet. Menschen mit hohen und niedrigen Schätzungen erhalten die Möglichkeit, ihre Begründung für ihre Schätzung zu erklären.

Wenn kein Konsens besteht, wird der Prozess so lange wiederholt, bis es einen gibt. Um sicherzustellen, dass die Diskussion strukturiert ist, kann der Moderator oder der Product Owner jederzeit eine Eieruhr umdrehen. Wenn diese abgelaufen ist, beendet man sofort alle Diskussionen. Die Idee hinter dem Einsatz von Planning Poker ist, den Einfluss der anderen Teilnehmer zu vermeiden. Wenn eine konkrete Zahl genannt wird, kann sie wie ein Vorschlag klingen und die Größe der anderen Teilnehmer beeinflussen. Planning Poker sollte die Menschen zwingen, unabhängig zu denken und gleichzeitig ihre Gedanken einzubringen. Dies erreicht man dadurch, dass alle Teilnehmer gleichzeitig ihre Karte vorzeigen müssen.

Ohne Wert ist wertlos

Der Product Owner ist dafür verantwortlich, dass der Product Backlog wertmaximierend angeordnet ist. Ziel ist es, das Team so früh wie möglich in die Lage zu versetzen, so viel Wert wie möglich zu liefern. Das ist jedoch leichter gesagt als getan. Wie bestimmt man, was wertvoller ist als etwas anderes? Der offensichtliche Weg, eine agile User Story zu bewerten, ist die Frage, welchen Nutzen sie bringen wird. Typischerweise erwartet man, dass neue Technologien entweder den Umsatz erhöhen, das Risiko mindern oder die Kosten senken.

Value Monopoly – Den Wert schätzen

Value Monopoly ist ein „Spiel“, das dem Planning Poker sehr ähnlich ist. Der Unterschied zum Planning Poker besteht darin, dass man den relativen Nutzen und nicht den relativen Aufwand schätzt. Value Monopoly ist eine schnelle und unterhaltsame Möglichkeit, den Nutzen von Features zu schätzen. Sie ermöglicht es allen Beteiligten, sich einzubringen, ohne lange Diskussionen zu führen. Die Grundidee ist, dass die Schätzung des relativen Nutzens zwischen den Merkmalen viel einfacher ist als den Nutzen in absoluten Zahlen zu schätzen.

Value Poker kann besonders nützlich sein, wenn der Product Owner mehrere verschiedene Stakeholder mit jeweils eigenen Prioritäten zu verwalten hat. Zu diesem Event kann man alle relevanten Stakeholder einladen. Für Value Monopoly erhalten alle Teilnehmer einen gewissen Betrag an Spielgeld. Bei der Bestimmung des Nutzens sollte eine durchschnittliche User Story mit einem Wert von beispielsweise 100 Einheiten beziffert werden. Alle Teilnehmer erhalten dann 100 Einheiten, pro zu bewertende Story.

Value Monopoly Session

Der Ablauf einer Value Monopoly Session ist dieselbe wie bei einer Planning Poker Session. Hier nochmal im Schnelldurchlauf: Ein Moderator leitet das Event. Eine Baseline für die Wertschätzung wird festgelegt, indem man ein gut verstandenes Item als Referenz verwendet und z.B. erklärt, dass dieses Merkmal 100 Einheiten wert ist. Der Product Owner gibt einen kurzen Überblick über die zu schätzende User Story und beantwortet alle Fragen der Teilnehmer.

Jetzt bestimmt jeder Teilnehmer, wieviel er für die einzelnen User Stories bezahlt. Dabei muss er mit seinem Budget haushalten, da er nicht mehr bekommt als am Anfang. Diejenigen mit den höchsten und niedrigsten Werten argumentieren ihre Entscheidung. Anders als beim Planning Poker findet nur eine weitere Wiederholung der Runde statt. Der Betrag wird dann addiert und zur User Story hinzugefügt. Dem Product Owner kann man hierbei ein Sonderrecht in Form eines Vetos oder eines doppelten Startbetrags einräumen.

Am Ende entscheidet der Product Owner

Die Schätzmethoden können ein guter Ansatz sein, um sicherzustellen, dass User Stories und andere Backlog Items verstanden und bezüglich Aufwands und Nutzen bewertet werden. Um zu vergleichen und zu priorisieren kann der Product Owner das Ergebnis aus Planning Poker (Aufwand) durch das Ergebnis des Value Monopolys (Nutzen) teilen. Der Wert für jedes Merkmal basiert auf der Perspektive des Unternehmens. Man darf jedoch nicht vergessen, dass der Product Owner letztendlich für das Backlogs verantwortlich ist und somit das letzte Wort hat.

User Stories richtig schätzen? Durch Poker? Fallst du jetzt nicht genau weißt, was ein gute User Story ausmacht, kannst du zuerst unseren Artikel aus der Serie Scrum Basics: User Stories lesen.

Das Product Backlog [link] ist ein aktives Taskboard, welches im Projektverlauf immer wieder angepasst wird. Möchtest du dazu mehr wissen, lies unseren Artikel aus der Serie Scrum Basics zum Thema Product Backlog Refinement [link]

Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick