Velocity (II)
Noch einmal zum Thema Velocity. Obwohl diese Metrik kein offizieller Teil von Scrum ist, ist sie in vielen Teams ein wesentliches Element der Umsetzung dieses Frameworks. Was dabei im Mittelpunkt steht, ist in der Regel der Planungs-Aspekt, also die Ableitung zukünftiger Arbeitsleistung aus der durchschnittlichen Story Point-Menge der letzten Sprints (siehe hier). Es gibt aber auch einen zweiten, seltener thematisierten Aspekt: eine Velocity erzeugt auch ein Work in Progress Limit (WIP Limit).
WIP Limits kennt man eigentlich aus Kanban und anderen Lean-Ansätzen, wo sie verwandt werden, um Überlastung und Multitasking zu vermeiden und den Arbeitsfluss zu verbessern. Die Idee ist eigentlich einfach: dadurch, dass eine Obergrenze für gleichzeitig bearbeitete Aufgaben eingeführt wird, werden weniger Arbeitspakete gleichzeitig begonnen, Multitasking und Koordinationsaufwände gehen zurück und Ergebnisse werden schneller fertig.
Das klingt erstmal gut, in der Realität kommt es allerdings regelmässig dazu, dass diese Obergrenzen zu hoch angesetzt werden. Wenn ihre Festlegung durch das Management erfolgt kann das z.B. daran liegen, dass die Kapazität der Umsetzungsebene zu optimistisch eingeschätzt wird (oft verbunden mit Wunschdenken in Bezug auf Fertigstellungstermine), oder dass möglichst vielen Stakeholdern das Gefühl gegeben werden soll, dass ihre Anliegen bearbeitet werden.
Aber auch wenn die Verantwortung für das Setzen der WIP Limits bei den jeweiligen Umsetzungsteams liegt, sind diese häufig zu hoch. Auch das kann daran liegen, dass versucht wird, möglichst viele Stakeholder zu befriedigen, mindestens genauso häufig ist aber eine unrealistisch optimistische Einschätzung der eigenen Leistungsfähigkeit oder eine Unterschätzung des mit bestimmten Tätigkeiten verbundenen Arbeitsaufwands.
Die Verwendung der Velocity sorgt dafür, dass die WIP-Obergrenzen realistischer werden. Wenn der durchschnittliche Output der letzten Sprints (Yesterdays Weather) bei 18 Punkten liegt, und demzufolge auch maximal diese Menge für den nächsten eingeplant werden soll, dann verschwinden "politische" Handlungsmotive und unsichere Faktoren wie die Selbst- und Fremdeinschätzung der Leistungsfähigkeit eines Teams aus dem Planungsprozess. Alleine dadurch werden die Planungen besser.
Der Vollständigkeit halber sei noch angemerkt, dass Scrum Teams die Planung ihrer Sprints eigentlich nicht an einem Output (in diesem Fall der Velocity) sondern an einem Outcome orientieren sollten, also an dem fachlichen Sprint-Ziel, dessen Umsetzungsaufwand eine gewisse Variabilität haben sollte, um auf ungeplante Entwicklungen reagieren zu können. Wenn aber (warum auch immer) eher Outcome-orientiert gearbeitet wird, kann ein auf der Velocity beruhendes WIP Limit eine gute Idee sein.
