Scrum Poker für Scrum-Teams

Scrum Poker ist der Name, unter dem viele Scrum-Teams Planning Poker kennen. Die Mechanik bleibt gleich: verdeckt wählen, gemeinsam aufdecken, über die Abweichungen reden. Geschätzt wird meist in Story Points. Wie eine Runde im Detail abläuft, zeigt unser Leitfaden zu Planning Poker an einem Beispiel. Hier geht es um die Fragen, die sich speziell im Scrum-Alltag stellen: An welcher Stelle im Sprint wird geschätzt, wer moderiert, und wozu dienen die Zahlen danach?

Schätzen im Scrum Guide: weniger Pflicht als gedacht

Im Scrum Guide kommt das Wort „Story Point“ nicht vor. Festgelegt ist dort nur zweierlei: Einträge im Product Backlog werden im Refinement zerlegt und präzisiert, bis sie in einen Sprint passen, und für die Größenschätzung sind die Developer zuständig, die die Arbeit später erledigen. Womit und wie sie schätzen, bleibt offen. Planning Poker, Velocity und Fibonacci-Karten stammen von anderswo: Story Points und Velocity sind größtenteils im Umfeld von Extreme Programming entstanden und in den 2000er-Jahren über Schulungen und Coaches in Scrum-Teams heimisch geworden.

Heißt es also im Unternehmen, Scrum schreibe Story Points vor, stimmt das nicht. Ob ein Team in Punkten, in Idealtagen oder in T-Shirt-Größen schätzt oder gar nicht, entscheidet es selbst. Ein guter Ort, diese Entscheidung zu überprüfen, ist die Retrospektive. Dort lässt sich offen fragen, wer die Zahlen eigentlich liest und was fehlen würde, wenn es sie nicht mehr gäbe. Fällt die Antwort dünn aus, darf das Team sein Vorgehen ändern.

Wann geschätzt wird

Für Scrum Poker gibt es im Sprint zwei naheliegende Gelegenheiten. Welche davon ein Team bevorzugt, prägt den ganzen Rhythmus.

Im Backlog-Refinement

Im Refinement, früher oft Grooming genannt, bringt das Team Backlog-Einträge in einen Zustand, in dem sie sich umsetzen lassen: verständlich formuliert, mit klaren Akzeptanzkriterien und klein genug für einen Sprint. Viele Teams reservieren dafür ein- oder zweimal pro Sprint etwa eine Stunde. Das ist der beste Platz für Scrum Poker. Die Storys werden erst in den folgenden Sprints umgesetzt, offene Fragen können also bis dahin geklärt werden. Und wenn eine Karte mit 40 auf dem Tisch liegt, bleibt genug Zeit, die Story zu zerlegen.

Ein Beispiel: Bei einem Mittelständler, der Maschinenteile fertigt, schätzt das Team im Refinement die Story „Lieferavis aus dem ERP an Großkunden per EDI senden“. Zwei Karten zeigen „?“, weil niemand weiß, welches EDI-Format die Kunden erwarten. Der Product Owner nimmt die Frage mit, klärt sie bis zum nächsten Termin mit dem Vertrieb, und die Story wird eine Woche später in Ruhe geschätzt, lange bevor sie im Sprint landet.

In der Sprint-Planung

In der Sprint-Planung legt das Team fest, was im kommenden Sprint umgesetzt wird und wie es die Arbeit angehen will. Sind die Storys bereits geschätzt, ist dieser Teil schnell erledigt: Das Team vergleicht die Summe der Punkte mit dem, was es in den letzten Sprints geschafft hat, und passt die Auswahl an. Nachgeschätzt wird nur, wo sich seit dem Refinement etwas Wesentliches geändert hat.

Wer dagegen alles erst in der Sprint-Planung schätzt, erlebt häufig lange, zähe Termine. Irgendwann wählt man die Karte, die am schnellsten zum Ende führt, und nicht die, die man für richtig hält. Wenn Ihnen das bekannt vorkommt, verlegen Sie die Schätzung ins Refinement.

Was der Scrum Master in der Runde tut

Ein Scrum Master, der nicht selbst mitentwickelt, legt keine Karte. Ein guter Teil seiner Arbeit liegt ohnehin vor dem Termin. Er klärt mit dem Product Owner, welche Einträge reif für eine Schätzung sind, und achtet darauf, dass die Akzeptanzkriterien schon im Ticket stehen. Wer im Refinement erst zehn Minuten lang Anforderungen zusammensucht, hat die Aufmerksamkeit des Teams verbraucht, bevor die erste Karte liegt.

In der Runde selbst behält er vor allem das Gefälle im Raum im Auge. Ein Product Owner setzt mit einem Nebensatz wie „Das ist ja nur eine kleine Anpassung“ schnell eine Erwartung; meist genügt die freundliche Bitte, solche Einschätzungen bis nach dem Aufdecken aufzuheben. In Remote-Runden mit ausgeschalteten Kameras gehen stille Kolleginnen und Kollegen leicht unter. Der Scrum Master kann sie gezielt nach ihrer Sicht fragen, sobald die Karten offen liegen, besonders wenn ihre Karte von der Mehrheit abweicht.

Findet eine Story keine Einigung, hält er fest, woran es hängt, und nicht nur, dass es hängt. Eine sichtbare Liste offener Fragen, jede mit einer verantwortlichen Person, verhindert, dass dieselbe Diskussion im nächsten Refinement von vorn beginnt.

Über den einzelnen Termin hinaus sammelt er Beobachtungen: Wie oft landet eine bereits geschätzte Story erneut auf dem Tisch? Bei welchen Themen taucht immer wieder „?“ auf? Solche Muster sind guter Stoff für die Retrospektive, weil sie zeigen, wo dem Team Wissen oder Vorbereitung fehlt.

Die Karten „?“ und ☕

Beide Karten sind ein Signal und verdienen eine Reaktion. „?“ bedeutet, dass Informationen fehlen, und der Scrum Master sollte klären, welche. ☕ bedeutet, dass das Team eine Pause braucht. Ausführlich geht die Fibonacci-Seite auf beide Karten ein.

Bugs, Spikes und Wartung

Ob auch Arbeit geschätzt wird, die keine neue Funktion liefert, hängt davon ab, was die Velocity eines Teams abbilden soll.

Soll sie zeigen, wie viel das Team insgesamt bewältigt, bekommen Fehlerbehebungen und Wartung Punkte wie jeder andere Eintrag. Die Planung stimmt dann auch in Sprints, die zur Hälfte aus Aufräumarbeiten bestehen. Außerdem sieht der Product Owner schwarz auf weiß, wie groß der aufgeschobene Brocken ist, wenn das ERP-Update zum dritten Mal nach hinten rutscht.

Soll sie dagegen nur den Fortschritt am Produkt messen, bleiben Bugs ohne Punkte. In fehlerlastigen Phasen sinkt die Velocity dann, und das ist gewollt: Der Rückgang macht sichtbar, dass Qualitätsprobleme gerade Kapazität binden.

Für Spikes, also zeitlich begrenzte Untersuchungen wie die Klärung des EDI-Formats oben, passt keine der beiden Varianten richtig. Ihre Dauer steht vorher fest, zu schätzen gibt es nichts. Viele Teams reservieren dafür ein festes Zeitbudget und planen den Sprint mit entsprechend weniger Kapazität.

Welche Linie ein Team wählt, ist weniger wichtig, als dass es sie durchhält. Wer die Regeln alle paar Sprints ändert, kann seine Velocity-Werte nicht mehr miteinander vergleichen.

Schätzen und Velocity

Die meisten Teams schätzen in Punkten, weil sie mit der Velocity planen wollen, also mit der Menge an Punkten, die sie pro Sprint abschließen. Scrum Poker hält diese Zahl stabil: Das ganze Team trägt jede Schätzung mit, und die Skala verschiebt sich weniger, als wenn eine einzelne Person schätzt. Wie Velocity berechnet wird und wofür sie taugt, erklärt die Seite zu Story Points.

Wann Scrum Poker überflüssig ist

Schätzrunden kosten Zeit, und nicht in jedem Team zahlt sich diese Zeit aus.

Manche Teams schneiden ihre Arbeit inzwischen so fein, dass die Einträge im Backlog ungefähr gleich groß sind. Dann sagt die Zahl erledigter Einträge pro Sprint fast dasselbe wie eine Punktsumme, und das Schätzen wird zur Formalie. Unter dem Stichwort #NoEstimates wird dieser Ansatz seit Jahren diskutiert.

Teams im Support oder Betrieb, deren Arbeit sich nach eingehenden Tickets richtet, planen ohnehin selten Sprints mit fester Auswahl. Sie fahren mit Kanban und Kennzahlen wie der Durchlaufzeit meist besser.

Entscheidend ist auch, wer die Zahlen braucht. Fragt außerhalb des Teams niemand nach Prognosen und erreicht das Team seine Sprint-Ziele auch ohne Punkte, sind die Schätzungen eine Übung ohne Publikum.

Anders sieht es aus, wenn Sprint-Ziele regelmäßig verfehlt werden oder die Fachabteilung wissen will, wann ein Vorhaben fertig ist. Dann sind gemeinsame Schätzungen oft der schnellste Weg zu einer belastbaren Antwort, und für die nächste Runde genügt ein kostenloser Online-Raum ohne Anmeldung.