Agile Schätzverfahren im Vergleich: Story Points, Planning Poker, T-Shirt-Grössen und Prognosen

Warum schätzen agile Teams relativ?

Menschen sind schlecht darin, die Dauer unbekannter Arbeit absolut zu schätzen, aber recht gut darin, zwei Aufgaben miteinander zu vergleichen. Die Frage «Wie viele Stunden dauert das?» löst Unsicherheit und Optimismus aus; die Frage «Ist das grösser oder kleiner als die Story, die wir letzte Woche umgesetzt haben?» lässt sich meist schnell und übereinstimmend beantworten. Agile Schätzverfahren nutzen diesen Effekt: Sie bewerten Einträge im Verhältnis zueinander und leiten erst aus der beobachteten Geschwindigkeit ab, wie viel in einen Zeitraum passt.

Der Scrum Guide schreibt kein Schätzverfahren vor. Er legt aber fest, dass die Developers, die die Arbeit erledigen werden, für die Grössenschätzung verantwortlich sind; der Product Owner kann sie beeinflussen, indem er hilft, Zielkonflikte zu verstehen ^[1]. Das ist ein wichtiger Grundsatz: Schätzungen, die von aussen vorgegeben werden, sind keine Schätzungen, sondern Zielvorgaben, und sie verlieren ihre Aussagekraft. Auch SAFe arbeitet mit relativen Schätzungen, etwa bei der Grösse von Features für die Priorisierung mit WSJF ^[2].

Welche agilen Schätzverfahren gibt es?

Was sind Story Points und wie werden sie genutzt?

Story Points sind eine relative Einheit für die Grösse eines Eintrags. Sie fassen Aufwand, Komplexität und Unsicherheit in einer Zahl zusammen. Meist wird eine an die Fibonacci-Reihe angelehnte Skala verwendet, etwa 1, 2, 3, 5, 8, 13, 20. Die wachsenden Abstände spiegeln wider, dass grössere Einträge unsicherer sind: Zwischen 13 und 14 lässt sich nicht sinnvoll unterscheiden, zwischen 13 und 20 schon. Einträge über einem bestimmten Wert, etwa 13, gelten als zu gross und werden zerlegt.

Wichtig ist: Story Points sind keine verschleierten Stunden. Ihr Wert entsteht erst im Zusammenhang mit der Velocity, also der Summe der Punkte, die ein Team in einem Sprint tatsächlich fertigstellt. Erledigt ein Team im Durchschnitt 30 Punkte pro Sprint, lässt sich ein Backlog von 150 Punkten auf etwa fünf Sprints schätzen. Story Points sind zudem teamspezifisch: Die 5 eines Teams ist nicht die 5 eines anderen, und ein Vergleich zwischen Teams ist nicht sinnvoll. Mehr dazu im Glossar unter Story Points.

Wie läuft Planning Poker ab?

1. 1Der Product Owner stellt einen Eintrag vor und beantwortet Fragen.
2. 2Jede Person wählt verdeckt eine Karte mit ihrer Schätzung.
3. 3Alle Karten werden gleichzeitig aufgedeckt.
4. 4Liegen die Werte weit auseinander, erklären die Personen mit dem höchsten und dem niedrigsten Wert ihre Gründe.
5. 5Das Team schätzt erneut, bis die Werte nahe beieinanderliegen.
6. 6Der vereinbarte Wert wird festgehalten, offene Fragen werden notiert.

Der eigentliche Wert von Planning Poker liegt in Schritt vier. Wenn eine Person 3 und eine andere 13 schätzt, haben sie unterschiedliche Vorstellungen vom Umfang oder von der Lösung. Diese Unterschiede vor der Umsetzung zu klären, verhindert spätere Überraschungen. Das gleichzeitige Aufdecken verhindert zudem, dass sich Teammitglieder an der Schätzung erfahrener Kolleginnen orientieren. Mehr zum Verfahren im Glossar unter Planning Poker.

Beispiel: Vom Backlog zur Releaseprognose

Ein Team schätzt für ein Release 24 Stories mit insgesamt 156 Story Points. Die Velocity der letzten sechs Sprints betrug 28, 34, 25, 31, 30 und 32 Punkte, im Durchschnitt 30, im ungünstigsten Fall 25 und im günstigsten 34. Daraus ergibt sich eine Bandbreite: Bei 34 Punkten pro Sprint dauert das Release etwa 4,6 Sprints, bei 30 Punkten 5,2 Sprints und bei 25 Punkten 6,2 Sprints. Gerundet bedeutet das fünf bis sieben Sprints, bei Sprints von zwei Wochen also zehn bis vierzehn Wochen.

Diese Bandbreite ist ehrlicher als eine einzelne Zahl und eine gute Grundlage für Gespräche mit dem Auftraggeber. Wird der Termin enger gewünscht, lässt sich ebenso ableiten, wie viele Punkte bis dahin realistisch sind und welche Stories folglich nach hinten rücken müssten. So wird die Schätzung zum Werkzeug für Entscheidungen über Umfang und Termin, nicht zur Zusage, die später eingefordert wird.

Geht es auch ohne Schätzung?

Ein wachsender Teil der agilen Praxis verzichtet auf aufwendige Schätzungen. Stattdessen werden Einträge so geschnitten, dass sie etwa gleich klein sind, und das Team zählt, wie viele pro Woche fertig werden. Der Kanban Guide definiert dafür Durchsatz als Anzahl fertiggestellter Einträge pro Zeiteinheit und Cycle Time als Zeit vom Beginn bis zum Abschluss eines Eintrags ^[3]. Aus der Verteilung dieser Werte lassen sich Prognosen ableiten, etwa mit welcher Wahrscheinlichkeit 40 Einträge in acht Wochen fertig werden.

Dieser Ansatz spart Zeit im Refinement und vermeidet Diskussionen über Punkte. Er setzt aber voraus, dass Einträge konsequent klein geschnitten werden und dass einige Wochen Daten vorliegen. Für neue Teams oder sehr unterschiedlich grosse Einträge bleiben relative Schätzungen sinnvoll. Wie Flussmetriken erhoben und genutzt werden, beschreibt der Beitrag Kanban einführen.

Welches Verfahren passt zu welchem Team?

Typische Fehler beim agilen Schätzen

• Story Points in Stunden umrechnen: Dann sind es keine relativen Schätzungen mehr, und der Vorteil geht verloren.
• Velocity als Leistungsziel: Teams, deren Velocity steigen soll, schätzen grösser, ohne mehr zu liefern.
• Velocity zwischen Teams vergleichen: Punkte sind teamspezifisch.
• Schätzung durch Product Owner oder Führungskraft: Die Developers schätzen, nicht andere.
• Zu viel Zeit für Schätzungen: Wenn die Diskussion über eine 5 oder 8 länger dauert als die Umsetzung, ist das Verfahren zu schwer.

Agile und klassische Schätzung im Vergleich

Klassische Projekte schätzen meist absolut in Personentagen, etwa mit der Dreipunktschätzung nach PERT. Beide Ansätze haben ihre Berechtigung: Für Angebote und Budgets braucht es oft absolute Werte, für die laufende Planung agiler Teams sind relative Schätzungen meist effizienter. In hybriden Projekten werden Epics zunächst grob in Personentagen geschätzt und dann im Team relativ verfeinert. Den klassischen Ansatz beschreibt der Beitrag Aufwandsschätzung im Hub Projektplanung. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.

Wie baut man eine gemeinsame Referenzskala auf?

Relative Schätzungen brauchen Bezugspunkte. Bewährt hat sich, zu Beginn zwei oder drei abgeschlossene Einträge als Referenz auszuwählen, etwa einen sehr kleinen mit dem Wert 1, einen mittleren mit 5 und einen grossen mit 13. Neue Einträge werden mit diesen Referenzen verglichen: Ist der neue Eintrag eher so gross wie die 5 oder eher wie die 13? Die Referenzen werden sichtbar gemacht, etwa am Board oder im Werkzeug, und gelegentlich überprüft, wenn sich das Team oder die Technik verändert hat.

Eine stabile Referenzskala ist wichtiger als die Wahl des Verfahrens. Sie sorgt dafür, dass eine 5 heute ungefähr dasselbe bedeutet wie vor drei Monaten, und macht die Velocity über die Zeit vergleichbar. Ändert sich die Bedeutung der Punkte unbemerkt, etwa weil das Team grösser schätzt, verliert die Prognose ihre Grundlage. Gut geschnittene Einträge erleichtern die Schätzung erheblich; wie User Stories zerlegt werden, zeigt der Beitrag User Stories schreiben.

Ein letzter praktischer Hinweis: Halten Sie die Zeit für Schätzungen bewusst knapp. Wenn ein Team für einen Eintrag länger als einige Minuten diskutiert, fehlt meist nicht die richtige Zahl, sondern Klarheit über den Inhalt. Dann ist es sinnvoller, den Eintrag zurückzustellen, offene Fragen mit dem Product Owner zu klären oder einen kurzen Spike einzuplanen, statt weiter über Punkte zu verhandeln.