Als ich ein Team zum ersten Mal in Story Points schätzen ließ, lehnte sich jemand zurück und sagte: „Sag mir einfach, wie viele Stunden ich hinschreiben soll.“ Eine faire Reaktion. Stunden fühlen sich konkret an. Punkte klingen, als hätte ein Berater sie erfunden, um schlau zu wirken. Aber nach ein paar Sprints verteidigte genau diese Person die Punkte gegenüber einem neuen Kollegen – weil sie am eigenen Leib gespürt hatte, was stundenbasierte Schätzungen mit einem Team anrichten.
Das Problem mit Stunden-Schätzungen
Stell dir vor, du fährst in eine Stadt 200 km entfernt. Wie lange dauert das? Du kannst gut raten – vielleicht zwei Stunden. Aber: Kannst du garantieren, auf die Minute genau anzukommen? Genau die halbe Strecke zur Halbzeit zu schaffen? Plötzlich löst sich die selbstbewusste Zahl auf. Baustellen, ein Unfall, eine Umleitung, ein langsamer Lkw auf einer Spur – nichts davon steckte in deiner Schätzung, und alles davon ist normal.
Softwarearbeit verhält sich genauso, nur schlimmer, weil die „Straße“ oft eine ist, die noch niemand gefahren ist. Wenn du eine unbekannte Aufgabe in Stunden schätzt, schätzt du nicht den Aufwand – du schätzt deinen eigenen Optimismus. Und Optimismus ist bemerkenswert konstant: Er liegt fast immer in dieselbe Richtung daneben.
Die Kernidee
Menschen sind schlecht in absoluten Schätzungen („das dauert 6 Stunden“), aber erstaunlich gut in relativen („das ist etwa doppelt so groß wie jenes“). Relatives Schätzen nutzt die Stärke statt die Schwäche.
Was ein Story Point wirklich ist
Ein Story Point ist eine Einheit relativen Aufwands. Er bündelt drei Dinge, die Arbeit schwerer machen: Komplexität (wie verschachtelt die Lösung ist), Ungewissheit (wie viel noch herauszufinden ist) und Umfang (wie viel reine Arbeit anfällt, selbst wenn sie einfach ist). Ein Punkt ist keine Stunde und will auch keine sein. Eine 5 ist etwa der fünffache Aufwand einer 1 – für dein Team, in eurer Codebasis, mit eurer Definition of Done.
- Komplexität – ein Bezahlvorgang mit Sonderfällen ist komplexer als eine Textänderung.
- Ungewissheit – die Anbindung einer fremden API birgt Unbekanntes.
- Umfang – 40 Templates von Hand zu ändern ist viel Arbeit, auch wenn jede Änderung trivial ist.
Weil Punkte relativ sind, funktionieren sie über Personen hinweg. Zwei Entwickler mit sehr unterschiedlichem Tempo können sich trotzdem einig sein, dass Aufgabe B etwa doppelt so groß ist wie Aufgabe A – auch wenn sie unterschiedliche Stundenzahlen aufschreiben würden. Genau diese geteilte Größeneinschätzung ist das eigentliche Ziel.
Ein konkretes Beispiel aus dem Planning
Hier ein leicht vereinfachtes Refinement, das ich moderiert habe. Wir begannen mit einem Anker: eine kleine, gut verstandene Story, über die sich alle einig waren, dass sie eine 2 ist – „Pflichtfeld zum Registrierungsformular hinzufügen“. Dann haben wir alles andere daran gemessen.
- „Pflichtfeld zur Registrierung“ – unser Anker, eine 2.
- „Inline-Validierung für dieses Feld“ – etwas mehr als der Anker, aber nicht doppelt. Sagen wir 3.
- „Passwortstärke-Anzeige mit API-Prüfung“ – klar größer, neue Integration, Unbekanntes. Eine 8.
- „Auth-Provider migrieren“ – niemand konnte es sauber mit dem Anker vergleichen. Das ist das Signal: zu groß zum Schätzen, also vor dem Schätzen aufgeteilt.
Beachte, was beim letzten Punkt passierte. Eine Stunden-Schätzung hätte ein selbstbewusst klingendes „drei Tage“ produziert, das in Wahrheit ein Achselzucken war. Relatives Schätzen brachte die Wahrheit ans Licht: Das ist keine Story, das ist ein Epic, und es musste aufgeteilt werden. Das ist kein Versagen der Schätzung – das ist die Schätzung, die ihre Aufgabe erfüllt.
Warum wir Punkte nicht in Stunden zurückrechnen
Der schnellste Weg, den Wert von Punkten zu zerstören, ist eine Tabelle mit „1 Punkt = 4 Stunden“. In dem Moment schätzen alle im Kopf in Stunden und multiplizieren – und du hast jedes Problem zurückgeholt, dem du entkommen wolltest, plus eine Schicht Zeremonie. Widersteh dem. Lass die Velocity, nicht einen Umrechnungsfaktor, Punkte mit Kalenderzeit verbinden.
Velocity: wie Punkte planbar werden
Nach zwei oder drei Sprints weißt du ungefähr, wie viele Punkte dein Team pro Sprint schafft. Diese Zahl – eure Velocity – ist die ehrliche Brücke zur Planung. Wenn ihr zuverlässig etwa 30 Punkte pro Sprint abschließt und der nächste Backlog-Block 60 Punkte hat, sind das etwa zwei Sprints Arbeit. Niemand musste über Stunden lügen, und die Prognose verbessert sich von selbst, sobald sich die Größeneinschätzung des Teams einspielt.
Probier das im nächsten Refinement
Wählt eine Story, die alle verstehen, und macht sie zum Anker. Schätzt die nächsten fünf Einträge nur durch Vergleich mit dem Anker – sagt nie eine Stundenzahl laut. Achtet darauf, wie viel schneller die Diskussion läuft und wie die Meinungsverschiedenheiten direkt auf versteckte Annahmen zeigen.
Häufige Einwände – und ehrliche Antworten
Jedes Team, das auf Punkte umstellt, durchläuft dieselbe Runde an Einwänden. Sie verdienen echte Antworten statt Parolen – hier sind die häufigsten und das, was sich in der Praxis bewährt hat.
- „Das Management will Termine, keine Punkte.“ – Das Management bekommt aus Punkten bessere Termine. Velocity macht aus Größen eine Prognose mit Erfolgsbilanz; ein Stapel Stundenschätzungen hat gar keine Rückkopplung. Zeig den Stakeholdern ein Burnup-Chart auf Basis von drei Sprints echter Velocity, und die Diskussion ist meist beendet.
- „Punkte sind doch nur Stunden mit Umweg.“ – Nur, wenn du sie umrechnest. Relativ gehalten, steckt in einem Punkt die Ungewissheit und Komplexität, die eine Stundenzahl stillschweigend verschluckt. Der ‚Umweg‘ ist genau das Feature.
- „Unsere Verträge rechnen nach Stunden ab.“ – Abrechnen und Schätzen sind verschiedene Aufgaben. Erfasse Ist-Stunden für die Rechnung, so viel du willst – aber speise diese Zahlen nicht zurück ins Sizing, sonst verankerst du jede künftige Schätzung.
- „Neue Kollegen wissen nicht, was eine 5 bedeutet.“ – Stimmt, und das ist in Ordnung. Sie lernen es in ein, zwei Refinements, indem sie die Vergleiche mit dem Anker beobachten. Diese Einarbeitung geht schneller, als den persönlichen Stunden-Optimismus eines Kollegen zu lernen.
Wann Stunden tatsächlich in Ordnung sind
Zur Ehrlichkeit gehört auch das: Punkte sind keine Religion, und Stunden sind nicht immer falsch. Für wirklich repetitive, gut verstandene Arbeit – eine Support-Rotation, routinemäßige Dependency-Updates, die vierte fast identische Report-Seite – können Stundenschätzungen völlig treffsicher sein, weil die Ungewissheit, für die Punkte gemacht sind, schlicht fehlt. Manche eingespielten Kanban-Teams lassen Schätzungen ganz weg und prognostizieren über Cycle-Time-Daten – auch das ist eine ehrliche Option.
Meine Faustregel für Teams: Je neuartiger die Arbeit, desto mehr zahlt sich relatives Schätzen aus. Sprint-Arbeit im Produktkontext ist meist neuartig genug, dass Punkte gewinnen. Besteht dein Backlog zu 90 % aus Routine-Tickets, zwing ihm kein Poker auf – miss stattdessen den Fluss.
Wo Planning Poker hineinpasst
Relatives Schätzen funktioniert am besten, wenn sich alle privat festlegen und gleichzeitig aufdecken – sonst verankert die zuerst genannte Zahl den Raum. Genau dafür ist Planning Poker da. Wenn du relatives Schätzen sofort mit deinem Team ausprobieren willst, kannst du eine kostenlose Session starten – ohne Konto – oder zuerst den ausführlichen Leitfaden zur agilen Schätzung lesen.
Gib ihm ein paar Sprints. Der Skeptiker in deinem Team kommt schneller an Bord, als du denkst – meiner tat es.