Story Points einfach erklärt

Story Points beschreiben, wie groß eine Aufgabe im Verhältnis zu anderen Aufgaben ist. Eine absolute Dauer steckt nicht darin. Bekommt eine Story 8 Punkte, heißt das nur: Das Team hält sie für deutlich größer als eine 3 und für etwas kleiner als eine 13. Mit diesem relativen Maßstab lässt sich erstaunlich gut planen, und so sind Story Points in vielen Scrum- und XP-Teams zur üblichen Einheit der agilen Schätzung geworden.

Woraus sich ein Story Point zusammensetzt

Hinter einer Schätzung in Story Points stehen drei Aspekte:

• Menge. Ein Formular mit dreißig Feldern macht mehr Arbeit als eines mit dreien, selbst wenn jedes Feld für sich trivial ist.
• Schwierigkeit. Eine Tarifberechnung mit vielen Sonderfällen umfasst vielleicht nur wenige Zeilen Code und kostet trotzdem viel Nachdenken und viele Tests.
• Unsicherheit. Eine Schnittstelle, die noch niemand im Team angefasst hat, lückenhafte Anforderungen oder ein Modul ohne Tests machen eine Aufgabe schwerer vorhersehbar. Je höher das Risiko, desto höher die Zahl.

Diese drei Aspekte werden nicht einzeln bewertet und addiert; jede Person verrechnet sie im Kopf zu einer Karte. Zwei gleiche Karten bedeuten deshalb nicht automatisch dieselbe Sicht. Beim Import neuer Tarifdaten legt die eine Entwicklerin vielleicht eine 8, weil dreißig Tarifarten einzeln abgebildet werden müssen, und ihr Kollege dieselbe 8, weil er dem Format der Lieferantendateien nicht traut. Solche Unterschiede ans Licht zu holen, ist ein Zweck von Planning Poker.

Warum keine Stunden?

Stunden wirken auf den ersten Blick konkreter, und außerhalb des Teams versteht man sie leichter. Relative Größen haben trotzdem einige Vorteile.

Vergleichen fällt Menschen leichter als Messen. Wie schwer ein Umzugskarton ist, kann kaum jemand auf das Kilo genau sagen. Ob er schwerer ist als der Karton mit den Büchern, merkt man beim Anheben sofort. Ähnlich ist es mit Software: „Ist das mehr Arbeit als der Passwort-Reset?“ lässt sich schneller und einheitlicher beantworten als „Wie viele Stunden brauchen wir dafür?“.

Stunden hängen zudem an der Person. Der Kollege, der die SAP-Anbindung vor drei Jahren selbst gebaut hat, ändert dort an einem Vormittag, wofür eine neue Kollegin eine halbe Woche braucht. Punkte beziehen sich auf die Aufgabe, und darauf kann sich das ganze Team einigen.

Außerdem verwandeln sich Stundenschätzungen gern in Zusagen. Aus „etwa 16 Stunden“ im Ticket wird schnell ein Termin, und wer ihn verfehlt, muss sich rechtfertigen. Eine Punktzahl liest sich eher als Größenangabe, über Risiken lässt sich dann offener sprechen.

Hinzu kommt, dass Stunden meist nur die reine Umsetzungszeit meinen. Was sonst im Sprint Zeit kostet, von der Urlaubsvertretung bis zur Rückfrage beim Datenschutz, taucht in keinem Ticket auf. Die Velocity misst dagegen, was am Ende tatsächlich fertig wurde, und enthält solche Reibungsverluste damit automatisch.

Der Maßstab: eine Referenz-Story

Wer relativ schätzt, braucht einen Bezugspunkt. Suchen Sie vor der ersten Runde ein oder zwei abgeschlossene Storys heraus, an die sich das Team gut erinnert, und legen Sie deren Werte fest.

Ein Team, das ein Stadtwerke-Portal betreut, könnte zum Beispiel die Story „Postleitzahl bei der Adressänderung gegen das Straßenverzeichnis prüfen“ als 3 festlegen und „Zählerstände der letzten drei Jahre als Diagramm anzeigen“ als 8. Jede neue Story wird dann daran gemessen: Kleiner als die PLZ-Prüfung? Eher in der Größenordnung des Diagramms?

Halten Sie die Referenzen gut sichtbar fest, etwa ganz oben im Backlog oder im Wiki des Teams. Nach einigen Monaten hat das Team den Maßstab im Gefühl. Wer neu dazukommt, braucht die Beispiele trotzdem.

Velocity: Planen mit den Punkten

Die Velocity ist die Summe der Story Points, die ein Team in einem Sprint abschließt. Werden Storys mit 13, 8, 5, 3 und 2 Punkten fertig, beträgt die Velocity 31. Eine Story, die am Sprintende fast fertig ist, zählt nicht mit. Das mag hart wirken, schützt aber vor geschönten Zahlen.

Aus einem Sprint allein lässt sich wenig ablesen. Nach drei oder vier Sprints ergibt sich eine Spanne, etwa zwischen 28 und 34 Punkten, und mit dieser Spanne plant das Team. Sie hilft bei der Frage, wie viel in den nächsten Sprint passt, und sie erlaubt dem Product Owner eine Prognose: Stehen noch rund 200 Punkte im Backlog für das Release und liegt die Velocity um 30, sind etwa sieben Sprints realistisch.

Bleiben Besetzung und Art der Arbeit halbwegs gleich, pendelt sich die Velocity in vielen Teams nach einigen Sprints ein. Einzelne Schätzungen liegen mal darüber und mal darunter, und über den Sprint hinweg gleicht sich ein Teil davon aus. Schwankt die Besetzung stark, bestimmt ungeplante Arbeit den Sprint oder verschiebt sich die Skala unbemerkt, bleibt die Zahl unruhig.

Wo die Velocity in Refinement und Sprint-Planung ins Spiel kommt, zeigt die Seite zu Scrum Poker.

Verbreitete Irrtümer

„Ein Punkt sind vier Stunden“

Irgendwann kommt der Wunsch, Punkte in Stunden umzurechnen. Mit einem festen Umrechnungsfaktor sind Sie aber wieder bei Stundenschätzungen, nur mit einem Zwischenschritt mehr und denselben Problemen wie oben. Wer einen Termin braucht, bekommt über die Velocity eine Prognose in Sprints.

„Velocity zeigt, welches Team besser arbeitet“

Team Nord schafft 45 Punkte pro Sprint, Team Süd 25. Daraus auf die Produktivität zu schließen, führt in die Irre. Jedes Team hat seine eigenen Referenz-Storys und damit seine eigene Skala. Werden Velocitys trotzdem teamübergreifend verglichen, steigen die Schätzungen, die Ergebnisse bleiben gleich, und für die Planung sind die Zahlen verdorben.

„Die Velocity muss steigen“

Eine gleichmäßige Velocity ist wertvoller als eine wachsende, weil sie belastbare Prognosen ermöglicht. Ein plötzlicher Sprung nach oben ist eher ein Anlass, die Skala zu prüfen, als ein Grund zum Feiern.

„Punkte eignen sich zur Leistungsbewertung Einzelner“

Story Points sind eine Schätzung des Teams für die Arbeit des Teams. Wer anfängt, Punkte pro Person zu zählen, bringt die Leute dazu, große Zahlen zu legen und Storys zu meiden, bei denen man anderen helfen müsste.

Dass Story Points bewusst grob sind und nach oben hin in immer größeren Sprüngen wachsen, erklärt die Seite zur Fibonacci-Skala.

Der Einstieg

Für den Anfang braucht es wenig. Das Team legt zwei Referenz-Storys fest, wie oben beschrieben, und nimmt das gängige Deck mit 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, „?“ und der Kaffeetasse. Für die erste Schätzrunde genügt ein kostenloser Online-Raum ohne Anmeldung, damit von Beginn an verdeckt gewählt wird.

Schätzen Sie zunächst nur, was in absehbarer Zeit ansteht, etwa die Einträge, die das Team im nächsten Monat angehen will. Ein komplett geschätztes Backlog veraltet schneller, als man es pflegen kann.

In den ersten Sprints geht es weniger um Treffsicherheit als um Übung. Die Velocity springt anfangs, und erst nach mehreren Sprints lässt sich absehen, in welcher Spanne sie liegt. Bis dahin plant das Team besser vorsichtig und nimmt eher etwas weniger in den Sprint.

Einmal im Quartal lohnt ein Blick auf die Referenz-Storys. Passen sie noch zu dem, was das Team heute baut? Wenn sich die Technik geändert hat, etwa weil eine neue Testumgebung vieles vereinfacht, verschiebt sich das Gefühl für Größen, und die Referenzen sollten mitziehen.

Ist eine Schätzung deutlich danebengegangen, gehört das in die Retrospektive, am besten als Frage nach Mustern: Unterschätzt das Team regelmäßig Arbeit an bestimmten Systemen oder Storys mit Abhängigkeiten zu anderen Abteilungen? Wer solche Muster kennt, kann sie bei der nächsten ähnlichen Story gezielt ansprechen, bevor die Karten fallen.