Vor Jahren nahm ich mal an einem Planning eines Scrum-Teams teil. Neben viel Celebration fiel mir da vor allem ein Effekt auf, den ich auch heute noch – Jahre später – als Zeitverschwendung ansehe: das (vermeintliche) Commitment eines Scrum-Teams auf Basis einer Zahl wie der Velocity aus vorherigen Sprints.

Was damals geschah

Das Scrum-Team sollte nur 50% seiner Zeit im Scrum arbeiten, die restlichen 50% mit anderen Tätigkeiten verbringen. Sie schätzten ihre Aufwände in idealen Personenstunden, aber der Effekt ist nach meiner Beobachtung gleich, wenn man hier auf ein abstraktes Schätzmaß wie Story Points setzt.

Zu Beginn des Plannings haben sie geplante Abwesenheiten aller Entwicklerinnen abgefragt. Danach kamen sie dann dazu, die Kapazität für den kommenden Sprint auszurechnen. Aus empirischen Daten wussten sie, dass sie an reiner Arbeitszeit ca. 40% von der verfügbaren Kapazität einplanen konnten. Also haben sie die Summe der verfügbaren Arbeitsstunden mit 0,4 multipliziert und hatte sie eine theoretische Kapazität von 180 Stunden für diesen Sprint. Damit waren bereits 30 Minuten des laufenden Sprint Plannings vorüber, bevor irgendjemand überhaupt einen Blick in die anstehenden Dinge geworfen hatte.

Die nächste Stunde verbrachte das Scrum-Team dann damit, die Kapazität zu verplanen. Eintrag um Eintrag wanderte in das weiter wachsende Sprint Backlog, bis die 180 Stunden voll waren. „Aber ich habe jetzt nichts zu tun.“ merkte ein Entwickler an. Also planten sie lustig Tätigkeiten für die Köpfe, die noch nicht ausgelastet waren ein, oftmals ungeachtet, ob das jetzt das wirklich dringlichste aus der Product Backlog Priorität ist. Am Ende hatten sie 320 Stunden für den Sprint eingeplant, alle hatten was zu tun, alle glücklich, richtig?

Eigentlich hätten sie sich die erste halbe Stunde komplett schenken können. Gerade weil das Scrum-Team anschließend gar nicht nach verfügbarer Kapazität planen konnte, weil sie dafür nicht cross-funktional genug aufgestellt waren. Ich denke, ich muss nicht erwähnen, dass am Ende des Sprints natürlich nicht alles fertig geworden ist.

Was sollte man stattdessen machen?

Ich arbeite mit Teams immer daran, dass sie die vorherige Velocity (deutsch: Geschwindigkeit) aus der Vergangenheit ignorieren. Stattdessen erarbeiten wir uns einen Plan, den wir für realistisch halten, also eine Menge an Arbeit, die wichtig ist für die kommenden zwei Wochen, aber gleichzeitig auch realistisch schaffbar erscheint.

Als letzten Sanity-Check nach dieser Planung zählen wir die Schätzungen auf den geplanten Product Backlog-Einträgen zusammen und vergleichen den Wert mit unserer Performance aus der Vergangenheit. Erscheint uns das ähnlich viel wie zuvor? Mehr? Viel mehr? Viel weniger? Je nach Ausgang der daraus entstehenden Diskussion kann man dann den Plan noch mal überarbeiten oder aus berechtigten Gründen damit in den Sprint starten. Alle relevanten Punkte wie „ich habe eine Woche Urlaub geplant“ werden bei der Erörterung der Gründe ohnehin aufkommen.

Das bedeutet, statt einer zeremonierten Zusammentragung von Velocity-Punkten können wir die Diskussion auch haben, wenn wir sie haben müssen. Brauchen wir sie nicht, lassen wir sie weg. Damit bleibt das Planning fokussiert auf den eigentlichen Sinn des Planens: das Planen der Inhalte, nicht der Kapazitäten.