Commitment-orientiertes Sprint Planning (Vorzüge gegenüber der Velocity)
Ich habe bereits zwei alternative Ansätze für das Sprint Planning erklärt:
Jetzt möchte ich gerne begründen, warum ich commitment-orientiertes Sprint Planning bevorzuge. Erst gibt es aber noch einmal eine kurze Erläuterung der beiden Begriffe.
Zusammenfassung der beiden Sprint Planning Ansätze
Bei velocity-orientiertem Sprint Planning wählt ein Team eine Reihe von Product Backlog Items aus, deren Einschätzung (meist in Story Points oder idealen Tagen) der durchschnittlichen Velocity des Teams entspricht. Bei commitment-orientiertem Sprint Planning nimmt sich das Team ein Product Backlog Item nach dem anderen vor und schätzt grob ein, welche und wie viele Tasks (Aufgaben) dabei involviert sein werden. Damit wird so lange weiter gemacht, bis die Teammitglieder das Gefühl haben, dass der Sprint voll ist. Weil “Commitment” häufig als “Garantie” missverstanden wird, wird dieser Ansatz auch immer öfter als “Kapazitätsbasierte Planung” bezeichnet.
Sprint-Velocity kann schwanken
Ein Blick auf das nachfolgende Diagramm hilft dabei, meine Präferenz für den commitment-orientierten Ansatz zu verstehen. Es zeigt die Velocity eines Teams bei neun aufeinanderfolgenden Sprints. Es fällt direkt auf, dass die Velocity nicht stabil ist. Sie ist bei jedem Sprint anders.
Der erste große Nachteil von velocity-orientiertem Sprint Planning ist, dass Velocity als Maßstab zu ungenau ist. Daher ist sie für die Kurzzeitplanung (z. B. einen Sprint) nicht zuverlässig genug. Erfahrungsgemäß schwankt Velocity um bis zu 20 Prozent. Darum ist es ganz normal, wenn ein Team mit einer eigentlichen Velocity von 20 in einzelnen Sprints eine Velocity von 16 oder 24 hat. Es sieht dann so aus, als ob das Team in diesen Sprints dann mehr bzw. weniger Arbeit erledigt hat. Und das trifft mit Sicherheit auch bei einigen Teams zu.
Diese Abweichung liegt aber zum Teil auch an den ungenauen Einheiten, die zur Einschätzung der Product Backlog Items verwendet werden. Die meisten Teams, die mit Story Points arbeiten, nutzen vorgegebene Werte wie die Fibonacci-Folge (1, 2, 3, 5, 8, 13) oder einfaches Verdoppeln (1, 2, 4, 8, 16). Wenn ein Team mit der Fibonacci-Folge arbeitet und behauptet, es habe eine Story mit fünf Points erledigt, hat es in Wirklichkeit aber vielleicht nur eine Story mit vier Points erledigt. Die Velocity wird so relativ schnell zu hoch bewertet. Auf lange Sicht gesehen ist das kein Problem, da dann das Gesetz der großen Zahlen einen Ausgleich schafft. Auf kurze Sicht kann es jedoch zu Problemen führen.
Der Verankerungseffekt von velocity-orientiertem Sprint Planning
Ein weiteres Problem beim velocity-orientierten Sprint Planning ist der Verankerungseffekt. Bei diesem Effekt werden Einschätzungen stark von vorherigen Informationen beeinflusst. Gute Beispiele dafür gibt es gerade in der Vorweihnachtszeit. Stellen Sie sich einmal vor, Sie gehen in ein Geschäft und finden eine Jacke, die Ihnen gut gefällt. Das Preisschild zeigt einen ursprünglichen Preis von 400 Euro. Dieser ist aber durchgestrichen und der neue Preis beträgt 200 Euro. Ihr Gehirn wird automatisch denken: “Super, eine Jacke im Wert von 400 Euro für nur 200 Euro!” Und genau das ist natürlich der Grund, warum der urspüngliche Preis mit angegeben wird. Eigentlich ist es egal, wie viel die Jacke einmal gekostet hat. Jetzt kostet sie nun mal 200 Euro und das ist das Einzige, was Ihre Kaufentscheidung beeinflussen sollte. Sobald der Preis von 400 Euro aber einmal in Ihrem Kopf verankert ist, ist es schwierig, ihn außer Acht zu lassen. Er lässt Sie unweigerlich denken, dass die Jacke für 200 Euro ein Schnäppchen ist.
Der Verankerungseffekt und velocity-orientiertes Sprint Planning
Was hat der Verankerungseffekt jetzt aber mit Sprint Planning zu tun? Nehmen wir als Beispiel ein Scrum Team in einem Sprint Planning Meeting. Es wurden bereits Stories ausgewählt, die der durchschnittlichen Velocity entsprechen. Die Teammitglieder überlegen dann, ob das wohl die richtige Menge an Arbeit ist. (Wie im Beitrag zu velocity-orientiertem Sprint Planning beschrieben, ist dabei auch das Identifizieren und Einschätzen von Tasks hilfreich.) Ein Team, das mit dem velocity-orientierten Ansatz arbeitet, wird häufiger vorschnell sagen “Ja, das schaffen wir!”, auch wenn es die Arbeiten in Wirklichkeit garnicht schaffen kann. Die Teammitglieder wissen schließlich, dass die ausgewählte Menge an Arbeit ihrer durchschnittlichen Velocity entspricht und so wird ihre Einschätzung beeinflusst. Genauso wäre es, wenn ich Ihnen die Jacke zeige und Sie das Preisschild mit den 400 Euro sehen können.
Wenn ich Sie jetzt frage: “Was meinen Sie kostet diese Jacke?”, nennen Sie sicherlich einen Betrag (zumindest annähernd) in der Höhe von 400 Euro, weil er sich in Ihrem Kopf verankert hat. Aufgrund dieses Verankerungseffekts wird ein Team mit einer durchschnittlichen Velocity von 20 mit hoher Wahrscheinlichkeit sagen, dass ein Sprint mit genau 20 Points gefüllt wurde – auch wenn die Arbeit eigentlich 16 oder 24 Points beträgt. Das kann dazu führen, dass einige Teams ab und zu weniger Arbeit erledigen, als möglich gewesen wäre. Oder ein Team nimmt sich so zu viel Arbeit vor. Oft wird in diesen Fällen dann eher das ein oder andere Item verworfen als hinzugefügt.
Velocity bei der Langzeitplanung
Sie glauben jetzt bestimmt, dass ich generell ein Gegner von velocity-orientiertem Sprint Planning bin. Das ist aber nicht ganz richtig. Ich halte diesen Ansatz für die Planung von einzelnen Sprints ungeeignet. Für längerfristige Planung finde ich ihn allerdings sehr gut geeignet. Velocity schwankt einfach zu sehr, als dass sie bei der kurzfristigen Planung nützlich wäre.
Um das zu verdeutlichen, stellen Sie sich einfach einmal vor, Sie würden in einer Autowaschanlage arbeiten. Bei Beginn Ihres ersten Arbeitstages sagt Ihr Chef Ihnen, dass Sie eine Quote zu erfüllen haben: Pro Stunde müssen Sie vier Autos waschen. Am Ende der ersten Stunde haben Sie allerdings nur drei Autos geschafft. Sollten Sie deswegen gefeuert werden? Natürlich nicht. Es war schließlich nur eine Stunde und vielleicht haben Sie ja drei große Autos gewaschen. Vielleicht war auch das Wetter schlecht und nur drei Personen haben ihre Autos zum Waschen vorbeigebracht. Am Ende des ersten Arbeitstages (acht Stunden) sollten Sie 32 Autos gewaschen haben. Sie haben aber nur 30 gewaschen. Ist es jetzt ein Grund Sie zu feuern? Eigentlich immer noch nicht. Und am Ende des ersten Monats? Wenn man von 20 Tagen und 32 Autos pro Tag ausgeht, sollten Sie dann 640 Autos gewaschen haben. Wird Ihr Chef Sie entlassen, wenn Sie lediglich 600 Autos geschafft haben? Vielleicht immer noch nicht, aber es wird langsam ersichtlich, dass Sie die Quote nicht erfüllen können – auch wenn es das gleiche Verhältnis ist, wie wenn Sie 30 anstatt 32 Autos am Tag waschen. Was, wenn Sie das ganze Jahr so weiter machen? Wenn die Quote gut durchdacht war – und alle anderen Mitarbeiter sie erfüllen – sollte Ihr Chef Sie vielleicht doch entlassen (oder versuchen anders mit Ihrer niedrigeren Produktivität umzugehen, aber darum geht es hier ja nicht).
Bei dieser Quote ist es nicht anders als bei der Velocity: Beide sind für einen längeren Zeitraum sinnvoll. Was würde es über die Unternehmensführung aussagen, wenn ein neuer Mitarbeiter schon nach einer Stunde gefeuert würde, weil er die Quote nicht erfüllen konnte? Dann müsste jeder Mitarbeiter sicherlich nach spätestens drei Tagen wieder entlassen werden. Diese Quote ist also eher für Zeiträume ab einem Monat anstatt für wenige Stunden geeignet. Ebenso ist Velocity eher für längere Zeiträume geeignet. Wenn ein Team 30 Product Backlog Items auszuliefern hat, kann es auf diese Weise gut einschätzen, wie lange es für jedes einzelne Item brauchen wird und wann es mit allem fertig sein wird. Ein Team mit nur drei Product Backlog Items sollte aber eher mit der althergebrachten Aufteilung der Items in kleinere Tasks arbeiten.
Sollte ich auf commitment-orientiertes Sprint Planning umsteigen?
Sollten Sie bereits mit velocity-orientiertem Sprint Planning arbeiten und das mit Erfolg, dann bleiben Sie dabei. Wenn Ihr Team Scrum gerade erst kennengelernt hat oder selbst einige der genannten Probleme bemerkt hat, dann wäre commitment-orientiertes Sprint Planning wohl die bessere Wahl.