Schätzungen im Sprint-Planning

Lohnt es sich, im Sprint-Planning Stunden für Tasks zu schätzen?
Die Frage diskutiere ich immer wieder mit Teams, denn in der Regel ist es eines der ersten Dinge, die ich Teams abgewöhne. Der Verzicht auf die Schätzung von Stunden für einzelne Tasks im Planning führt eigentlich immer zu einem besseren weil fokussiertem Planning.

Warum man die Stundenschätzung nicht unbedingt benötigt und warum das Planning dadurch häufig besser wird, will ich im Folgenden erklären.

Die Schätzung von Stunden ist in den Teams, die ich bisher beobachtet habe, einer der langwierigsten Teile im Sprint-Planning. Das liegt zum Einen daran, dass Stundenschätzungen sehr personenabhängig sind. Ein Entwickler meint, dass die Aufgabe in 3 Stunden erledigt ist, ein anderer denkt, dass mindestens 8 Stunden nötig sind.
Und beide haben recht.
Die in Teams beliebtesten Lösungen sind dann entweder die 2-Punkt-Schätzung, also die goldene Mitte zu wählen oder den Task im Planning bereits mit einem Bearbeiter zu versehen. Gerade letzteres widerspricht aber zum Einen der Philosophie von Scrum und führt zum anderen zu Over-Commitments.
Bei ersterer Variante geht das Team instinktiv davon aus, dass sich die Aufwände über den Sprint verteilt ausmitteln werden. Das passiert in der Regel auch. Um diesen Effekt zu nutzen, ist es aber gar nicht notwendig, die Zeit für die Stundenschätzung zu investieren.
Ich bringe den Teams immer bei, einfach rückwärts zu rechnen. Ein Task sollte maximal einen Tag lang in Bearbeitung sein. Das bedeutet, dass das Team mindestens Anzahl der Teammitglieder x Anzahl der Tage des Sprints Tasks benötigt. Als Obergrenze hat sich Anzahl der Teammitglieder x Anzahl der Tage des Sprints x 2 bewährt. Wenn ein Team seine Velocity kennt – was nach spätestens drei Sprints der Fall sein sollte – können die Teammitglieder sich Stories im Umfang der Velocity aus dem Backlog ins Planning holen und schneiden diese dann in Tasks.
Ist die Anzahl der Tasks nach dem Planning zwischen den beiden Grenzwerten, kann die Arbeit losgehen.
Liegen die Anzahl der Tasks deutlich unter der Mindestzahl und das Team ist sich sicher, nichts vergessen zu haben, kann noch eine kleine (!) Story dazu genommen werden und die Velocity steigt vielleicht. Liegt sie deutlich darüber, lässt man eine Story weg.

Die Methode, sich von der Anzahl der Tasks leiten zu lassen und davon auszugehen, dass sich die Aufwände der Tasks im Sprint ausmitteln, funktioniert nach meinen Beobachtungen sehr zuverlässig. Der Verzicht auf die Stundenschätzung führt aber noch zu einem anderen hoch interessanten Effekt.
Teams, die aufhören Stunden zu schätzen, beschäftigen sich viel intensiver mit dem Inhalt der Tasks. Die Qualität der Tasks steigt deutlich. Die Diskussionen im Planning drehen sich nicht mehr um die Frage, wer was wie schnell implementieren kann, sondern um Fragen über bestmögliche Lösungen und die dafür notwendigen Tasks. Insgesamt steigt die Motivation und das Planning ist viel kürzer. So bleibt als weiterer Effekt dem Team auch noch mehr Zeit für die Realisierung der Aufgaben.

Nach einer kleinen Weile, ca. 3-4 Sprints, haben die Teammitglieder ein recht gutes Bauchgefühl dafür, wie weit ihr Scrum Board mit Tasks gefüllt sein muss, um ein Commitment abzugeben. Dann benutze ich die Ober- und Untergrenze eigentlich nur noch in meiner Rolle als ScrumMaster, um das Team zu fragen, ob sie sich wirklich sicher sind, wenn eine der Grenzen gerissen wird. Aber das passiert sehr selten.

Der Verzicht auf die Stundenschätzung bringt dem Team also Vorteile. Das Gegenteil habe ich beobachtet, wenn Teams mit Stundenschätzungen auf Tasks beginnen. Da das Stundenschätzen langwierig und öde ist, neigen Teams sehr schnell dazu, weniger Tasks zu schneiden. Denn hat man weniger Tasks, ist die Phase des Schätzens kürzer. Dafür sind die Tasks entsprechend größer. Und das wiederum führt dazu, dass der Flow während des Sprints eher träge wird, weil große Tasks lange in Bearbeitung sind. Damit ergeben sich dann oft Wartezeiten durch Abhängigkeiten, die zum Absinken der Velocity führen. Im nächsten Planning achten diese Teams dann oft darauf, noch genauer zu schätzen, was meist der Beginn einer Negativspirale mit noch weniger Tasks ist. Ein Extrem, das ich gesehen habe, waren 10 Tasks für 4 Stories bei einem 7-Personen-Team und 2-Wochen-Sprints.
Und: Ja, das Commitment wurde verfehlt 😉

Insgesamt denke ich, dass die von mir gemachten Beobachtungen sich auch auf andere Teams übertragen lassen und unabhängig von Projektinhalten oder Technologien sind. Und ich empfehle Scrum-Teams, den Verzicht auf Schätzungen auszuprobieren. Nach drei bis vier Sprints wird man auf den Verzicht nicht mehr verzichten wollen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.