0 0 Stimmen
Artikel-Rating

Mit dem Velocity-Konzept versuchen viele Scrum Teams abzuschätzen, wie viele Features, User Stories oder Aufgaben sie in einem Sprint umsetzen können. Wird der Planungsrahmen jedoch größer – beispielsweise bei der Releaseplanung – wird es trotzdem schwierig. Wie viele Must-Have Features können/sollen wir in einem Release unterbringen? In diesem Artikel zeige ich Dir, warum Du mit einer Velocity Range besser planen kannst als mit einer fixen Velocity-Kennzahl.

Release Backlog – Beispiel

Nehmen wir als Beispiel ein Product Backlock, das zu Beginn der Releaseplanung User Stories, Features und Aufgaben mit exakt 200 Story Points besitzt. Stellen wir uns diese Aufgaben einmal als Kuchen vor, sähe das also so aus wie auf der rechten Seite.

Der Product Owner möchte seine Kunden und Nutzer pro Quartal mit einem Update zu versorgen. Das Entwickler-Team arbeitet in Sprints von einem Kalendermonat Dauer. Wir haben – bis zur Fertigstellung – also 4 Releases mit jeweils 3 Sprints. Das Team hat bereits 1 Jahr an dem Projekt gearbeitet und eine (historische) Velocity von 18 Story Points/Sprint.

Rein rechnerisch sieht das Ganze also erstmal vollkommen in Ordnung aus: Wir haben ein Product Backlog mit 200 Story Points und mit unseren 12 Sprints erzielen wir mit der aktuellen Velocity sogar 216.

Releaseplanung - Product Backlog

Das Problem

Nun gibt es aber in jedem Product Backlog wichtige und weniger wichtige Features. Wenn wir mit einer fixen Velocity-Kennzahl arbeiten, kann es schwierig werden, festzulegenfestzulegen, welche Funktionen wir mit dem ersten Release auf jeden Fall zur Verfügung stellen können. Selbst dann, wenn wir wissen, dass wir (im Schnitt) 54 Story Points pro Release schaffen werden, wäre es ziemlich schwierig, im ersten Release ausschließlich Must-Have Features unterzubringen. (Was machen wir, wenn Unvorhergesehenes eintritt? Welches Feature wollen wir streichen?)

Wenn wir mit Must-Have Features in Höhe von nur 30 Story Points planen, haben wir einen guten Puffer. Aber falls es zum Endtermin in einem Jahr doch einmal eng werden sollte, ist fraglich, ob wir in unseren vier geplanten Releases tatsächlich alle Must-Have Features unterbringen werden können. Dann haben wir im vierten und letzten Release zu viele Must-Have Features übrig und haben das Problem nur vom Anfang ans Ende geschoben.

Release 1 - Fixed Velocity

Hinzukommt, dass unsere (historische) Velocity ein Durchschnittswert der letzten 12 Monate ist. Tatsächlich schwankte die Performance des Teams ziemlich stark. Die gemessenen Velocity-Werte der letzten Monaten waren: 8, 15, 13, 28, 16, 15, 21, 24, 21, 23, 20, 12. Wir sind also trotz eines Velocity-Durchschnittswertes von 18 mit großen Schwankungen zwischen 8 und 28 Story Points konfrontiert. Was ist, wenn unser Team beim ersten Release drei Sprints hinlegt, bei denen es nur jeweils 8 Story Points erreicht? Aber wie wahrscheinlich ist das? Wir haben also im Grunde zwei Probleme:

  • Mit einer fixen Velocity-Kennzahl teilen wir unser Release-Backlog lediglich in erledigt (will have) und nicht erledigt (won’t have) ein.

  • Wenn wir Velocity ausschließlich als Durchschnittswert angeben, macht das die Schätzung zusätzlich schwierig, da wir Schwankungen nicht berücksichtigen können.

Mehr Planungssicherheit mit Velocity Range

Mit dem Konzept der Velocity Range geben wir nicht mehr (nur) eine fixe Kennza