Den einen oder anderen mag es verwundern, aber im Scrum Guide fällt das Wort Velocity kein einziges Mal. Das Wort Done hingegen 40 Mal. Leider wird Agilität oft oberflächlich mit mehr Geschwindigkeit gleichgesetzt. Und im Endergebnis stimmt das sogar. Geschwindigkeit entsteht aber nicht dadurch, dass man schneller arbeitet, sondern sorgfältiger – und damit auf den ersten Blick langsamer ist. Oder um ein chinesisches Sprichtwort zu bemühen:

Wenn Du schnell sein willst, gehe langsam.

Den meisten Scrum Mastern, die ich kenne, ist diese Tatsache durchaus bewusst. Woran es hapert, ist es, dieses Fakt auch in der eigenen Organisation zu kommunizieren. Wenn wir als Scrum Master jedoch selbst den Begriff Velocity nutzen, stellen wir uns letzten Endes selbst ein Bein. Denn wenn wir den Fokus auf Qualität setzen möchten, dann ist es dumm, wenn wir nur von Geschwindigkeit sprechen.

Schnelligkeit ensteht durch Qualität und nicht durch Geschwindigkeit

Der wahre Nutzen von Scrum entsteht dann, wenn wir uns darauf konzentrieren, zum Ende eines Sprints mit unseren Aufgaben wirklich fertig (also done) zu sein und Nutzen für unseren Kunden stiften. Nur ein fertiges, potenziell nutzbares Increment erzeugt Transparency und hilft dabei, Komplexität zu reduzieren und somit bessere Anpassungen unseres Plans (inspect & adapt) durchzuführen.

Hohe Qualität verhindert technische Schuld, die uns (auf lange Sicht) langsamer machen wird. Häufige Auslieferungen von fertigen Increments liefern stetig neuen Nutzen und reduzieren die Wahrscheinlichkeit, falsche Wege einzuschlagen, die uns letztlich wieder mehr Zeit kosten werden. Wenn wir also hohe Qualität als Mittel für Schnelligkeit nutzen wollen, dann sollten wir uns genau darauf konzentrieren.

Velocity erzeugt ein Wettrüsten

Da es in Scrum so ist, dass das Entwicklerteam für die Aufwandsschätzung der Aufgaben zuständig ist, entsteht durch Geschwindigkeitsdruck von außen eine gefährliche Spirale. Sprechen wir – auch als Scrum Master – permanent von Velocity, drängt sich der Wunsch, dass ein Team auch immer schneller wird, in den Vordergrund. Das Entwicklerteam wird – bewusst oder unbewusst – User Stories in Zukunft höher schätzen. Aus einer einfachen 3 wird eine 5, aus einer 8 wird eine 13. Und schon schießt die Velocity des Teams in die Höhe. Alle sind zufrieden, weil das Team plötzlich schneller ist – oder zumindest sieht es so aus. Dabei sollte im Vordergrund stehen, dass das Team immer bessere Qualität liefern kann.

Je höher die Story Points einer User Story jedoch sind, desto größer wird auch das Bedürfnis innerhalb des Teams werden, dass diese User Story „irgendwie“ doch fertig ist. (Wenn man 13 Punkte verliert, schmerzt das eben mehr, als wenn man nur 5 Punkte verliert.)

Verteile keine anteiligen Story Points

Wenn wir in Scrum von Completion statt von Velocity sprechen, dann stellt sich auch nicht mehr die Frage danach, ob ein Scrum Team von den ursprünglichen 13 Story Points einer User Story anteilig 12 Story Points erhält, wenn diese am Ende des Sprints nur zu 99 Prozent fertig geworden ist. Das Team mag viel Aufwand betrieben haben und vielleicht sogar besonders schnell gearbeitet haben, aber es ist nicht dort angekommen, wo es hin wollte. Oder verkürzt gesprochen:

Velocity: 12 – Completion: 0

Completion statt Velocity

Deshalb bin ich als Scrum Master mittlerweile dazu übergegangen, nicht mehr von Velocity zu sprechen, sondern von Completion. Completion stellt stärker in den Vordergrund, dass es um fertige User Stories geht. Das ist zwar eine reine Umbenennung, aber es hilft mir, auch Nicht-Scrummies zu vermitteln, worum es bei Scrum wirklich geht: Qualität.