Agile Schätzung: Zeit vs. Story Points

Wenn agile Teams ihre Arbeit schätzen, stehen sie vor einer grundlegenden Wahl: Sollen sie in vertrauten Zeiteinheiten wie Stunden und Tagen schätzen, oder sollten sie das abstraktere Konzept der Story Points verwenden? Beide Ansätze haben ihre Berechtigung, und beide haben überzeugte Befürworter. Die Abwägungen zwischen ihnen zu verstehen ist für jedes Team, das effektiv planen und prognostizieren möchte, unerlässlich.

Zeitbasierte Schätzung

Zeitbasierte Schätzung ist genau das, was sie klingt: einer Aufgabe eine konkrete Dauer zuzuweisen. „Dieses Feature wird drei Tage dauern.” „Dieser Bugfix sollte ungefähr zwei Stunden in Anspruch nehmen.” Sie ist die natürlichste Form der Schätzung für die meisten Menschen, da wir es bereits gewohnt sind, in unserem Alltag zeitlich zu denken.

Für Teams, die aus klassischen Wasserfall- oder Projektmanagement-Umgebungen kommen, fühlt sich zeitbasierte Schätzung sofort vertraut an. Stakeholder verstehen sie ohne Erklärung, Projektmanager können Zahlen direkt in Gantt-Charts einfügen, und die Abrechnung nach Zeit ist für kundenorientierte Projekte unkompliziert.

Vorteile zeitbasierter Schätzung:

• Intuitiv für Stakeholder und neue Teammitglieder
• Lässt sich direkt auf Lieferpläne und Ressourcenplanung übertragen
• Einfach zu kommunizieren ohne spezielles Agile-Wissen
• Gut geeignet für routinierte, gut verstandene Aufgaben

Nachteile zeitbasierter Schätzung:

• Anfällig für Optimismus-Bias – Entwickler unterschätzen systematisch, wie lange Dinge dauern
• Erzeugt impliziten Druck, Stunden- oder Tagesschätzungen wie Verpflichtungen zu behandeln
• Berücksichtigt Unsicherheit, Komplexität und Abhängigkeiten nur unzureichend
• Individuelle Schätzungen variieren stark je nach Erfahrung und Kontext, was die Aggregation auf Teamebene erschwert

Story Points

Story Points entstanden als Antwort auf die Schwächen zeitbasierter Schätzung. Statt zu fragen, wie lange eine Aufgabe dauert, fragen Story Points, wie komplex eine Aufgabe im Vergleich zu anderen, bereits geschätzten Aufgaben ist. Ein Story Point ist eine Einheit relativen Aufwands, keine Zeiteinheit.

Diese Unterscheidung ist wichtig. Zwei Entwickler benötigen möglicherweise sehr unterschiedlich viel Zeit, um dasselbe Feature zu implementieren – aber sie sollten sich grundsätzlich einig sein, ob dieses Feature komplexer oder einfacher als ein anderes Feature ist, das beide kennen. Story Points messen das gemeinsame Verständnis von Komplexität, nicht individuelle Ausführungsgeschwindigkeit.

Teams verwenden typischerweise die Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21), um Story Points zu vergeben, und nutzen Planning Poker, um Konsens-Schätzungen zu erzielen. Mit der Zeit tracken Teams ihre Velocity – die durchschnittliche Anzahl der Story Points, die pro Sprint abgeschlossen werden –, was eine verlässliche Grundlage für Sprint-Planung und Lieferprognosen schafft.

Vorteile von Story Points:

• Berücksichtigt die inhärente Unsicherheit der Softwareentwicklung
• Reduziert den Stress von Zeitverpflichtungen – Points dreht sich um Komplexität, nicht um Versprechen
• Fördert Schätzung auf Teamebene statt individuelle Heldenleistungen
• Skaliert gut für große, komplexe Projekte mit hoher Unsicherheit
• Velocity-basierte Prognosen verbessern sich mit der Zeit, wenn das Team sich kalibriert

Nachteile von Story Points:

• Erfordern eine Kalibrierungsphase, bevor die Velocity des Teams aussagekräftig wird
• Abstrakt für Stakeholder, die nicht mit agilen Praktiken vertraut sind
• Können missbraucht werden, wenn Teams Story Points zurück in Stunden umrechnen
• Neue Teammitglieder brauchen Zeit, um den Referenzrahmen des Teams zu verstehen

Die versteckten Kosten der Umrechnung von Story Points in Stunden

Einer der häufigsten Fehler ist es, Story Points für die interne Planung zu verwenden und sie dann für externe Berichte in Stunden umzurechnen. Das untergräbt beide Systeme gleichzeitig. Es entsteht ein fiktiver Umrechnungskurs („ein Story Point entspricht X Stunden”), der individuelle Unterschiede, Kontext und Unsicherheit ignoriert. Teams beginnen, ihre Schätzungen zu manipulieren, um sowohl das Punkt-Ziel als auch das versteckte Stunden-Ziel zu treffen – und die Integrität des Schätzprozesses erodiert schnell.

Wenn Stakeholder zeitbasierte Prognosen benötigen, ist der richtige Ansatz, Velocity-Daten zu nutzen, um Sprint-Abschluss und Release-Termine zu projizieren – nicht so zu tun, als wären Story Points heimlich Stunden.

Wann was wählen

Zeitbasierte Schätzung eignet sich, wenn:

• Das Team routinierte, gut verstandene Aufgaben mit stabilen Anforderungen erledigt
• Kundenabrechnung an geleistete Stunden gebunden ist
• Stakeholder nicht mit agilen Praktiken vertraut sind und nicht geschult werden können
• Aufgaben klein, klar abgegrenzt und mit geringer Unsicherheit behaftet sind

Story Points eignen sich, wenn:

• Das Team an komplexen, unsicheren oder langfristigen Projekten arbeitet
• Gemeinsames Eigentum an Schätzungen statt individueller Verpflichtungen gewünscht wird
• In Sprints geplant wird und zuverlässiges Velocity-Tracking aufgebaut werden soll
• Die Reduzierung von Schätz-Stress und die Förderung ehrlicher Einschätzungen Priorität hat

Fazit

Weder zeitbasierte Schätzung noch Story Points sind die objektiv richtige Wahl. Entscheidend ist, dass das Team seinen gewählten Ansatz konsequent und ehrlich anwendet und der Versuchung widersteht, falsche Gleichsetzungen zwischen den beiden Systemen herzustellen. Wer neu in Agile ist und nicht weiß, wo man anfangen soll: Viele Teams stellen fest, dass Story Points – einmal verstanden – einen nachhaltigeren und kooperativeren Weg zu verlässlicher Planung bieten.