Releaseplanung mit Velocity Range

Home » Blog » Scrum » Releaseplanung mit Velocity Range
  • Releaseplanung mit Velocity Range

Releaseplanung mit Velocity Range

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 Kennzahl an, sondern legen einen Rahmen fest, zwischen dem sich unsere Velocity (höchstwahrscheinlich) bewegen wird. Eine Möglichkeit, die Velocity Range zu berechnen, ist der sogenannte Velocity Range Calculator, den Mike Cohn auf seiner Homepage Mountain Goat Software anbietet. Damit kannst Du über historische Velocity-Werte einen Median-Wert (!) und die projizierte Range des Scrum Teams berechnen. (Für die Statistik-Fans unter Euch gibt es dort auch eine ausführliche Erklärung der Formel.)

Geben wir die historischen Velocity-Daten aus unserem Beispiel dort ein, kommen wir auf einen Median-Wert von 18 und eine Velocity Range, die zwischen 13 und 23 Story Points pro Sprint liegt. Nun haben wir nicht mehr nur eine Durchschnittsgeschwindigkeit, sondern eine Ober- und Untergrenze.

Release 1 - Velocity Range

Die Untergrenze definiert somit unsere Will-have Features (39 Story Points). Die Obergrenze legt unsere neue Kategorie Might-Have Features fest (69 Story Points). Das sind diejenigen Tasks, die wir also nur eventuell schaffen werden. Alles, was mehr als 70 Story Points hat, werden wir definitiv nicht schaffen. Unsere Release Backlog wird dann wie links zu sehen eingeteilt werden.

Es fällt auf, dass wir nach diesem Schema eventuell sogar mehr in unseren drei Sprints schaffen könnten, als mit einer fixen Velocity-Kennzahl (nämlich 69 Story Points statt 54).

Das ist durchaus kein Widerspruch, denn auch wenn der Durschnittswert (und der Median) bei 54 liegt, ist es ja auch möglich, dass das Pendel zu unseren Gunsten ausschlägt und unser Scrum Team mehrere Sprints mit einer höheren Velocity durchführt. Auch das lässt sich mit einer fixen Velocity-Kennzahl nur schwer abbilden.

Drei mögliche Szenarien mit Velocity Range

Mit unserer neuen Dreiteilung durch die Velocity Range sind wir in der Lage, viel einfacher festzulegen, wie viele Must-Have-Features wir für unseren ersten Release einplanen sollten. Bis 39 Story Points sind wir auf Basis unserer historischen Velocity-Werte auf der sicheren Seite. Denkbar sind bis zu 30 weitere Story Points, also ein Maximum an 69. (Der Median-Wert von 54 gibt uns übrigens noch eine weitere Orientierung.) Nun sind drei verschiedene Szenarien denkbar:

Releaseplanung A (Auf der sicheren Seite)

Releaseplanung B (Einen Versuch ist es wert)

Releaseplanung C (Schlechte Neuigkeiten)

Das war’s von meiner Seite. Jetzt würde ich natürlich gerne von Dir wissen, ob Du mit dem Konzept der Velocity Range etwas anfangen kannst oder ob Dir das Ganze schon zu komplex (oder kompliziert) ist. Hast Du vielleicht auch schon mit Velocity Range gearbeitet? Dann schreib mir doch einfach einen Kommentar unter den Artikel. Ich freu mich auf Dein Feedback!

Mehr Infos

Scrum & Agiles Projektmanagement

Du möchtest Scrum in Deinem Unternehmen oder Deiner Abteilung einführen, weißt aber nicht wie Du vorgehen sollst? Ich berate Dich gerne!

Mehr Infos

Von |2018-09-30T23:36:07+00:0030. September 2018|Kategorien: Modelle, Scrum|Schlagworte: , , |0 Kommentare

Über den Autoren:

Ich glaube an eine Arbeitswelt, in der Menschen darauf brennen, am Montag endlich wieder zur Arbeit gehen zu dürfen. Deshalb helfe ich Menschen, Unternehmen und Organisationen, Arbeitsumgebungen so zu gestalten, dass sich Motivation und Engagement entfalten können.

Hinterlasse einen Kommentar

Newsletter

Diese Website benutzt Cookies und anderes Teufelswerk. Näheres dazu findest Du auf unserer Datenschutz-Seite. Verwalte hier Deine Einstellungen Einverstanden

Angebote von Drittanbietern

Hier kannst Du auswählen, welche Angebote von Drittanbietern Du während Deines Besuches auf dieser Webseite erlauben möchtest und welche nicht.