Scrum Velocity berechnen

Lade dir jetzt den kostenlosen Velocity Template
im Excel Template, inklusive Anleitung herunter.

Inhaltsverzeichnis

Man kann lange darüber streiten, aber die wohl wichtigsten KPI, oder meinetwegen zwei der wichtigsten top 5 KPI in Scrum sind die Sprint-Accuracy und die Scrum Velocity.

Ersterer ist prozessual betrachtet schon fast eine Voraussetzung für den zweiten, darauf komme ich später noch zurück.

Sprint-Accuracy gibt an, wie oft ein Team es schafft, das Sprint-Commitment zu halten, bzw. wenn man es etwas genauer haben möchte, wie dicht Teams daran kommen.

Aber hierum soll es heute nicht gehen. In diesem Artikel geht es um die Scrum Velocity.

Genau genommen geht es darum, eine Methode zur Berechnung und Darstellung der Velocity zu beschreiben, die geeignet ist, einen wirklichen Trend zu zeigen und eine Prognose zu erlauben.


Ich möchte Ihnen außerdem ermöglichen, die folgend beschriebene Trendanalyse auch in Ihren Projekten einzusetzen und stelle Ihnen dazu das Excel-Template (natürlich kostenfrei) zur Verfügung:

Dein kostenloser Velocity Template
Lade dir jetzt den kostenlosen Velocity Template im Excel Template, inklusive Anleitung herunter.

Velocity in Scrum ist zweifellos eine schwierige Angelegenheit

Nicht nur, dass es Scrum Teams oft sehr schwer fällt ihre Velocity konstant zu halten oder sogar zu steigern und damit Organisationen die Möglichkeit einer einigermaßen zuverlässigen Prognose für Aufwände, Dauer, Kosten (you name it) neuer Features zu geben.

In Scrum Velocity überhaupt adäquat zu messen und zwar so, dass man daraus sinnvolle Rückschlüsse ziehen kann, ist ebenso häufig ein Problem.

Wie oft saßen wir schon alle vor unseren JIRA Velocity Charts, haben die Fieberkurve betrachtet und gedacht „Hmmm…. Aha, soso. Und was sagt mir das jetzt?“.

Dann ziehen wir uns auf unsere Burndown-Charts zurück und hoffen, dass wir damit durchkommen, erst durch den Sprint und dann durch das Projekt.

Heute früh kamen mir zwei Schüler auf dem Fahrrad entgegen und ich konnte nur einen kurzen Fetzen Ihrer Unterhaltung aufschnappen. Der eine sagte „Hoffentlich kommen die Vokabeln dran, die ich gelernt habe.“. Wir alle kennen diesen Satz, aber mit über 30 Jahren Abstand klingt er nicht mehr so dramatisch, dafür aber um so lustiger. Ziehen Sie selbst die Parallele.

Das Problem mit der Scrum Velocity fängt leider schon viel früher an.

Um eine Velocity messen zu können, hat Herr Scrum uns eine Währung geschaffen: die Story Points (SP). Leider werden die Story Points in der Regel oft erst falsch verstanden und dann falsch angewendet, was die Berechnung der Velocity nicht leichter macht. Über Story Points habe ich bereits geschrieben, bei Interesse lesen Sie dort mal nach.

Zusammenfassend repräsentieren Story Points die Komplexität einer Story in Bezug auf ihren Aufwand und sind damit weder Komplexität noch Aufwand, sondern die Beziehung zwischen beiden. Sie werden daher auch oft in Fibonacci Zahlen angegeben. Da müsste es bei den meisten schon klingeln, denn Fibonacci-Folgen verwendet der geneigte Naturforscher zur Darstellung des Wachstums von Populationen. 

Nehmen wir mal an, Sie verwenden Story Points richtig. Dann bleibt noch das Problem der Berechnung der Scrum Velocity.

Nehmen wir auch mal an, sie hätten auch die anderen SCRUM Kurse erfolgreich absolviert und vergeben in einem Sprint die Story Points erstens nur für Stories (und nicht für Bugs, ja alles schon gesehen) und auch nur dann, wenn die Story abgeschlossen wurde. Leider ist die Sprint-Accuracy in Teams oft nicht sehr ausgeprägt.

Wenn es so wäre und auch sonst alles gut läuft, würde im JIRA Ihr Velocity Chart ungefähr so aussehen:

Jira Velocity
Die Darstellung basiert auf einer Simulation von 6 Sprints und den dort erreichten Story Points.
Velocity

Das sieht doch sehr gut aus. Leider ist dies eine Simulation. Und zwar eine, die der Wirklichkeit leider nicht oft auch nur entfernt gerecht wird.

Scrum Velocity: Die Wirklichkeit sieht doch oft so aus

Jira Velocity im Wirklichkeit

Hm, ein Trend lässt sich daraus ja nun wirklich nicht ablesen. Sie erinnern sich an die oben beschriebene Situation. Aber woran liegt das? Wir müssen nicht lange raten.

Oft werden Stories im aktuellen Sprint fast fertig. Fast fertig ist aber nicht fertig und daher gibt es auch keine Kekse im aktuellen Sprint.

Da sie aber im darauffolgenden Sprint dann schnell fertig gemacht werden, ernten wir im Folgesprint dann umso mehr Story Points.

Dann kommen noch diverse Einflussfaktoren dazu, die Bug-Rate, Kapazitätsschwankungen etc. Diese sind tatsächlich reale Einflussfaktoren auf die Velocity. Aber sie lassen sich kaum noch trennen von der Sprintgrenzen-Unschärfe.

Scrum Velocity berechnen: Wie lösen wir das Problem?

Wir lösen das Problem ganz einfach. Wir trennen die richtige Praxis – Story Points nur dann zu vergeben, wenn eine Story geschlossen wird, egal ob in diesem Sprint oder im nächsten – von der Berechnung der realen Scrum Velocity.


Sollten Sie unter einem agile Contract arbeiten, dann werden sie im Sprint natürlich weiterhin nur für die erzielten Story Points bezahlt, können die Velocity des Teams aber dennoch unabhängig von dieser Logik real messen.

Sehen wir uns mal die folgende Tabelle an. Dort haben wir jede Story aufgeführt mit dem Datum, wann sie geschlossen wurde und zu welchem Sprint sie demzufolge gehört.

Velocity

In dieser Tabelle sehen wir uns nicht die Summen pro Sprint an, sondern die Stories selbst. Wir sehen, in welchem Sprint sie ursprünglich waren und wann sie tatsächlich geschlossen wurden.

Darauf bilden wir nun einen Trend ab und erhalten dann diese viel aussagekräftigere Ansicht.

Velotrend

Der Vorteil dieser Methode ist, dass wir statt der Verwirrung des sprintbasierten Velocity Charts einen echten Trend ausmachen können.

Das Team ist zwar ganz offenkundig nicht besonders gut in Bezug auf die Sprint-Accuracy, denn es ist ihm ein paarmal nicht ganz gelungen, die Stories, die sie sich vorgenommen haben, in diesem Sprint auch zu liefern. Dafür Schande über das Team. Aber Ihre Velocity wächst im Zeitverlauf recht kontinuierlich, so schlecht sind die Jungs und Mädels also gar nicht.

Zumindest wissen sie jetzt genau, woran sie arbeiten müssen und das Management kann sich wieder etwas beruhigter hinlegen.

Der Scrum Prozess ist ohnehin sehr sensibel und auch ziemlich diffizil. Außerdem bietet Scrum ohnehin nicht gerade üppig viele KPI’s, die irgendwie nach einer Zahl aussehen.

Wenn dann noch eines dieser KPI’s durch eine unglückliche Darstellung oder ungeeignete Messmethode die Realität verzerrt oder Dinge miteinander vermischt, die besser getrennt werden sollten, dann wird die Aufgabe ein Team voranzubringen schon sehr schwer.

Es soll hier nicht falsch verstanden werden: Die Art und Weise, wie JIRA das Velocity Chart darstellt ist nicht eigentlich falsch. Aber hier werden Sprint-Accuracy und Velocity so unglücklich vermischt, dass ein Zerrbild herauskommt und mit dem eigentlich so unglaublich wertvollen Instrument der Velocity-Betrachtung kaum noch sinnvoll gearbeitet werden kann.

In der vorgeschlagenen Methode gibt es viel mehr Messpunkte. Damit ist es egal, ob ein Team einwöchige- oder zweiwöchige Sprints hat, oder auch mal den Rhythmus wechselt.

Wir referieren hier auf das tatsächliche Close-Date, nicht auf das Sprintende.

Das bringt nicht nur mehr Messpunkte, d.h. wir müssen nicht so lange warten, bis ein Trend erkennbar wird, sondern auch mehr Unabhängigkeit vom gelebten Scrum-Prozess. Und sogar Kanban-Teams können in Ihrer Velocity gemessen werden, die sonst immer so ganz unter dem Radar fliegen.
Dein kostenloser Velocity Template
Lade dir jetzt den kostenlosen Velocity Template im Excel Template, inklusive Anleitung herunter.
Klicke hier, um Artikel mir demselben Tags zu sehen:
Weitere interessante artikel für dich:
Behindert das neue AÜG Scrum Projekte? | scagile.work Blog
Scrum
Behindert das neue AÜG Scrum Projekte?

Was hat die Neuregelung des AÜG mit Scrum zu tun? Ich meine viel und möchte auf die neuen Herausforderungen, die sich daraus für die Planung von SCRUM Projekten in vielen Unternehmen ergeben in diesem Artikel eingehen.

Read More »
This is a teaser for another article
Lorem ipsum dolor sit amet consectetur adipiscing elit dolor
Category
This is a flip box
its not any H tag
This is the heading
Lorem ipsum dolor sit amet consectetur adipiscing elit dolor
Click Here
This is a flip box
its not any H tag
This is the heading
Lorem ipsum dolor sit amet consectetur adipiscing elit dolor
Click Here
This is a flip box
its not any H tag
This is the heading
Lorem ipsum dolor sit amet consectetur adipiscing elit dolor
Click Here
This is a flip box
its not any H tag
This is the heading
Lorem ipsum dolor sit amet consectetur adipiscing elit dolor
Click Here
Item One

Lorem ipsum dolor sit amet, consectetur adipisi cing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. 

Item Two

Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Item Three

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat. Lorem ipsum dolor sit amet, consectetur adipisi cing elit, sed do eiusmod.

1
Advanced Tools
Add more power to Elementor using our creative elements and make your projects look prettier than ever before.
2
All-in-One Solution
Find all the tools you’ll need to create advanced websites in one place. Stop waisting time searching for solutions.
3
Nonstop Updates
We strive to innovate when it comes to functionality. Our mission is to be the best, come and join the ride.

Article name

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit