Story Points: Arbeit einschätzen, ohne Stunden zu raten
Story Points sagen, wie groß eine Arbeit im Vergleich zu anderen ist, nicht wie lange sie dauert. Woher sie kommen, wie du sie nutzt und wann du Stories zählst.
Story Points sind eine Zahl, die ein Team einer Arbeit gibt, um zu sagen, wie groß sie im Vergleich zu anderen Arbeiten ist. Sie messen keine Stunden. Eine 5 ist größer als eine 3 und kleiner als eine 8. Was eine 5 bedeutet, legt das Team fest, das sie benutzt.
Woher sie kommen
Story Points stammen aus Extreme Programming. In Story Points Revisited beschreibt Ron Jeffries, ein früher Praktiker der Methode, wie es damals war. XP-Teams schätzten Stories zuerst in Zeit. Dann nutzten sie „ideale Tage“, also die Zeit, die ein Paar ohne Unterbrechung bräuchte, und multiplizierten sie mit einem Belastungsfaktor von etwa drei, um echte Zeit zu erhalten. Die Beteiligten fanden die Tageszahlen verwirrend, deshalb begannen die Teams, von „Punkten“ zu sprechen. Jeffries sagt, dass er den Begriff vielleicht erfunden hat, und wenn ja, bedauert er es heute. Mike Cohns Agile Estimating and Planning (2005) half, die Praxis zu verbreiten.
Scrum verlangt keine Story Points. Der Scrum Guide erwähnt sie nicht. Er sagt, dass die Developer, die die Arbeit erledigen, für ihre Schätzung verantwortlich sind, und lässt ihnen die Wahl des Weges.
Warum Menschen sie nutzen
Hinter Story Points steckt wenig harte Forschung. Die Gründe, die Teams nennen, sind praktisch.
Vergleichen ist leichter als vorhersagen. Es ist schwer zu sagen: „Das dauert zwei Tage.“ Leichter ist zu sagen: „Das ist ungefähr doppelt so groß wie jene andere Story.“ Eine relative Skala erlaubt dem Team, sich zu einigen, ohne über Stunden zu streiten.
Die Umrechnung kommt aus deiner eigenen Erfahrung. Menschen sind optimistisch, was ihre eigene Zeit angeht. In einer Studie von 1994 von Roger Buehler, Dale Griffin und Michael Ross sagten Studierende voraus, dass ihre Abschlussarbeiten im Schnitt 33,9 Tage dauern würden. Sie brauchten 55,5 Tage (Journal of Personality and Social Psychology). Punkte vermeiden ein Versprechen in Stunden. Du addierst die Punkte, die dein Team in den letzten Sprints tatsächlich abgeschlossen hat. Diese Zahl, die Velocity heißt, zeigt dir, wie viel du beim nächsten Mal übernehmen kannst.
Sie decken die gesamte Arbeit und den Zweifel ab. Eine Punkteskala umfasst Testen, Review und das Unbekannte. Je größer die Zahl, desto unsicherer ist sie.
Jeffries selbst beklagt heute den Missbrauch und zieht es vor, Stories so lange zu schneiden, bis jede klein ist. Das ist eine faire Alternative, und sie kommt unten wieder vor.
So nutzt du sie
- Wähle eine Referenzstory. Nimm eine fertige Story, einige dich darauf, dass sie eine 2 oder eine 3 ist, und schätze andere im Vergleich dazu.
- Schätze die ganze Aufgabe. Schließ Entwurf, Umsetzung, Test und Review ein. Mehr Arbeit, mehr Komplexität und mehr Unsicherheit treiben die Zahl jeweils nach oben.
- Nutze eine begrenzte Skala. Zahlen im Fibonacci-Stil (1, 2, 3, 5, 8, 13) zwingen zur Wahl zwischen „größer“ und „kleiner“ und beenden den Streit über 6 oder 7.
- Setz eine Obergrenze. Eine Story über 13 ist zu groß, um sie zu planen. Teile sie auf.
- Zähl nur fertige Stories. Am Ende des Sprints addierst du die Punkte der erledigten Stories. Eine Story, die fast fertig ist, bringt noch nichts.
- Plane mit dem Durchschnitt. Nimm den Mittelwert deiner letzten Sprints und nutze ihn als Velocity.
So könnte ein Team es sehen. „Eine Checkbox für ‚Angemeldet bleiben‘ hinzufügen“ ist eine 2. „Passwort per E-Mail zurücksetzen“ ist eine 5, mit E-Mail, Ablauf und Tests. „Berichte als PDF mit Layout exportieren“ ist eine 13 und muss wohl aufgeteilt werden. Wenn die letzten drei Sprints 18, 22 und 20 Punkte abgeschlossen haben, plant das Team etwa 20.
Nutze Planning Poker, um die Zahlen gemeinsam festzulegen.
Fehler, die du vermeiden solltest
- Punkte in Stunden umrechnen. „Ein Punkt ist ein halber Tag“ macht aus einer relativen Skala eine schlechte Uhr.
- Die Velocity verschiedener Teams vergleichen. Die Punkte jedes Teams bedeuten etwas anderes. Eine größere Zahl heißt nicht, dass mehr geschafft wurde.
- Menschen an der Velocity messen. Wird eine Punktzahl zum Ziel, schätzen Leute hoch, um es zu erreichen.
- Teilgutschriften geben. Zähl eine Story, wenn sie fertig ist, und nicht vorher.
- Nachträglich neu schätzen. Die Zahlen zu ändern, wenn die Arbeit fertig ist, verdeckt, was du gelernt hast.
- Jeder nutzt seine eigene Skala. Der Wert der Zahl liegt darin, dass das Team sie teilt.
Wann sie das falsche Werkzeug sind
- Wenn deine Einträge ungefähr gleich groß sind. Zähl die Einträge. Jeffries zieht es vor, Stories klein zu schneiden, statt sie zu schätzen.
- Für persönliche Aufgaben. Wenn du eine Dauer brauchst, nimm Minuten.
- Wenn ein Kunde nach Stunden bezahlt. Er will Stunden, also schätze Stunden.
- Wenn die Punkte nichts bringen. Jeffries sagt, man solle sie lassen, wenn sie nicht helfen, und behalten, wenn das Team sie mag.
- Für ein brandneues Team. Ohne Sprints hinter sich gibt es keine Velocity. Schließ ein paar Sprints ab und beobachte, was ihr tatsächlich schafft.
In Prior
Wähle beim Anlegen oder Bearbeiten eines Projekts unter Projekttyp die Option Agil · Scrum oder Agil · Scrumban. Aufgaben dieses Projekts werden dann in Punkten geschätzt statt nach Priorität.
- Punkte setzen. Die Aufgabendetails haben eine Zeile Story Points mit einer Reihe von Karten: 0, ½, 1, 2, 3, 5, 8, 13 und 21, dazu Entfernen. Der Composer für neue Aufgaben hat einen Chip Punkte mit demselben Satz. Ein Wert außerhalb des Satzes, etwa 4, bekommt eine eigene Karte. Punkte reichen von 0 bis 999 in Schritten von 0,5. Der Hinweis sagt es: „Die Größe der Arbeit, nicht ihre Dauer.“
- Die Größe sehen. Ein Punktechip ersetzt das Prioritätssymbol P1 bis P4 auf Karten und in Zeilen: drei Balken, wobei einer bis 1 Punkt aufleuchtet, zwei bis 3 und drei bis 13. Über 13 zeigt der Chip ein korallenrotes „!“, weil die Story aufgeteilt werden sollte. Eine Aufgabe ohne Schätzung zeigt leere Balken und die Angabe Nicht geschätzt. Die Priorität bleibt bearbeitbar.
- Gemeinsam schätzen. Der Tab Planning Poker schreibt den vereinbarten Wert in die Aufgabe. Siehe den Leitfaden zu Planning Poker.
- Zu große Arbeit aufteilen. Der Pokertisch bietet Aufgabe aufteilen an, und Prior AI schlägt die Teile vor, wenn dein Konto Pro hat. Siehe Eine Story aufteilen.
In einem Scrum-Projekt werden Zyklen zu Sprints. Jede Sprintkarte zeigt den Fortschritt, etwa „13 von 21 Pkt. erledigt“, und wie viele Aufgaben nicht geschätzt sind. Der Sprint-Editor zeigt die Punkte, die du zugesagt hast. Die Zusammenfassung Velocity über den Karten ist der Durchschnitt der erledigten Punkte in den letzten drei abgeschlossenen Sprints, auf eine Nachkommastelle gerundet. Solange kein Sprint abgeschlossen ist, steht dort: „Schließe einen Sprint ab, um deine Velocity zu sehen.“
Punkte bleiben erhalten, wenn du ein Projekt zurück auf Kanban oder Standard stellst. Sie werden ausgeblendet, nicht gelöscht. Sie wandern außerdem mit der Synchronisierung, dem Datenexport und den MCP-Werkzeugen mit. Eine numerische Linear-Schätzung wird beim Import zu Story Points. Die vollständige Referenz steht unter Story Points und Sprints.