Warum „No Estimates“ keine Option ist
Der Durchschnitt ist als statistische Größe immer anfällig für Ausreißer. Das kann dazu führen, dass er seine Präzision verliert. Natürlich gilt auch hier das Gesetz der großen Zahl, denn Ausreißer verlieren ihr Gewicht, wenn die Menge der Werte steigt. Bekanntlich bestätigen Ausnahmen aber auch die Regel und ein Unglück kommt selten allein.
Nehmen wir einmal an es gäbe wichtige Aufgaben, bei denen das Interesse der Stakeholder an einer zuverlässigen Vorhersage der Liefertermine besonders hoch ist. Diese Aufgaben sind unterschiedlich groß und komplex und eine der Aufgaben stellt einen Ausreißer dar. In dieser Situation wird es fast unmöglich, realistische Liefertermine zu nennen und einzuhalten.
Außerdem kann durch „No Estimates“ das gefährliche Missverständnis entstehen, dass die Team-Performance vergleichbar wäre: Team A braucht im Schnitt 7 Tage für eine Aufgabe, Team B benötigt 14 Tage. Team A ist also doppelt so schnell wie Team B – oder doch nicht?
Die Betrachtung der Durchlaufzeit schafft keine Vergleichbarkeit zwischen Teams. Sondern vielmehr die Größe von Aufgaben, die Anzahl und Erfahrung der Teammitglieder sowie die Neuartigkeit der Aufgabe für ein Team. Die Größe des Teams lässt sich in einer Durchlaufzeitenbetrachtung berücksichtigen, die Erfahrung und die Neuartigkeit sind schwer quantifizierbar und der Anforderungsschnitt des Product Owners bestimmt die Größe der Anforderung.
Agiles Schätzen – Was ist das überhaupt
Agiles Schätzen geschieht im Gegensatz zu klassischen Schätzverfahren nicht in einer absoluten Einheit, wie bspw. dem Aufwand in Personentagen oder Kosten in Euro. Stattdessen werden Aufgaben im Vergleich zu anderen Aufgaben eingeschätzt. Das Ziel ist es festzustellen, ob Aufgaben größer, gleich groß oder kleiner als andere Aufgaben sind. Als Referenz für die relative Einschätzung werden Aufgaben verwendet, die bereits umgesetzt wurden.
Geschätzt wird die Größe einer Aufgabe, die sich aus unterschiedlichen Bestandteilen zusammensetzt. Welche Bestandteile das sind, bestimmt jedes Team individuell. Wichtig ist, dass die Bestandteile konstant bleiben, damit die Schätzungen innerhalb des Teams vergleichbar bleiben.
Beispiele für die Bestandteile der Größe
- Aufwand
- Komplexität
- Abhängigkeiten
- Anzahl durchzuführender Schritte
Praxistipp
In der Praxis werden Aufgaben, die einen Schätzwert von mindestens 20 Story Points besitzen nicht unmittelbar umgesetzt, sondern zerteilt, da das Risiko von Unerwartetem während der Umsetzung zu hoch ist.
Planning Poker
Um mit Planning Poker die Größe von Anforderungen im Team zu schätzen, benötigt jedes Teammitglied ein (virtuelles) Kartendeck mit den Zahlen der unreinen Fibonacci Reihe. Außerdem benötigt das Team mindestens eine Referenzaufgabe, die den Wert 5 erhält. Alle anderen Aufgaben werden im Vergleich zu der Referenzaufgabe eingeschätzt.
Praxistipp
Wenn pro Wert der Reihe eine Referenzaufgabe existiert, können die Schätzenden die Abstufung zwischen den Werten der Aufgaben leichter einschätzen.
Ablauf von Planning Poker
Eine Planning-Poker-Runde funktioniert in 6 Schritten:
Die Aufgabe wird vorgestellt
Verständnisfragen werden geklärt
Die Schätzenden werden gebeten ihren Schätzwert aus dem Kartendeck auszuwählen und die Karte verdeckt vor sich zu legen
Wenn alle ihre Karten vor sich liegen haben, werden die Karten gleichzeitig aufgedeckt
Die Personen mit dem höchsten und dem niedrigsten Schätzwert tauschen sich aus, wie sie zu ihrer Einschätzung gekommen sind
Die Gruppe versucht einen Kompromiss zu finden. Gelingt dies nicht, wird neu geschätzt oder die Aufgabe zurückgestellt, bis die notwendigen Informationen für eine Schätzung vorliegen
Praxistipp
Wenn nach der zweiten Schätzrunde kein Konsens gefunden wird und die Schätzwerte nur geringfügig abweichen, sollte der Median oder der Mittelwert verwendet werden. Maximale Präzision ist nicht das Ziel der Schätzung.
Was passiert mit den Story Points der Aufgaben?
Die Story Points der Aufgaben werden addiert, auf dessen Umsetzung sich das Team in einer Iteration commited. Die Summe wird velocitiy genannt und ist gleichbedeutend mit dem Workload, den ein Team in einer Iteration umsetzen kann. Durch das iterative Vorgehen erhöht das Team die Genauigkeit seiner velocity und kann auf Basis der Schätzung und der Erfahrungswerte sein Commitment abgeben. Durch die Kenntnis über seine velocity ist es dem Team möglich, präzise einschätzen zu können, was die tatsächlichen Ergebnisse einer Umsetzungsiteration sein werden.
Lange Rede, kurzer Sinn – Warum ist agiles Schätzen sinnvoll?
Aus agilem Schätzen ergeben sich zwei wesentliche Vorteile für Teams und Organisationen:
Der strukturierte Austausch über Aufgaben führt zu einem besseren gemeinsamen Verständnis unter den Teammitgliedern. Dies fördert die Wissensverteilung im Team und das Teambuilding. Der Schätzwert ist für diesen Vorteil weniger relevant. Zusätzlich gibt der Ablauf des Schätzens dem Team eine Struktur, an der sie sich orientieren können. Dies ist vor allem für Teams hilfreich, die in agilem Arbeiten noch nicht so geübt sind.
Die regelmäßige Schätzung hilft Teams besser einschätzen zu können, was sie in einer Umsetzungsiteration leisten können. Durch das Beobachten und Lernen aus der Vergangenheit präzisiert sich die velocitiy über die Zeit und das Commitment wird präziser. Daraus ergibt sich eine größere Vorhersagbarkeit für umgesetzte Aufgaben, was sich positiv auf die Erwartungen der Stakeholder auswirkt.
Zusammengefasst bedeutet das: Schätzen in agilen Teams ist kein Muss, hilft aber in vielerlei Hinsicht:
- Kommunikation und Auseinandersetzung mit Aufgaben im Team werden strukturiert
- Teams entwickeln ein gemeinsames Verständnis für ihre Aufgaben
- Teams haben eine Metrik, um ihren Workload präzise steuern zu können
- Die Erwartungshaltung bei Stakeholdern kann aktiv gemanaged werden
- Die Gefahr vermeintlicher Vergleichbarkeit von Teams sinkt
Darüber hinaus sind Schätzwerte eine wichtige Grundlage für einige KPIs, mit denen die Weiterentwicklung von Teams und Organisationen zielgerichtet strukturiert werden kann.