Scrum Velocity berechnen

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.

Scrum Velocity berechnen | scagile Blog

Inhalt dieses Artikels

Dein kostenloser Velocity Template

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

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:

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.

Story Points: Wieso, weshalb, warum, aber vor allem wie?

Was sind Story Points, warum gibt es sie überhaupt und wie werden sie denn nun berechnet? All das erfahren Sie hier. Sie werden überrascht sein, was alles in ihnen steckt!

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:

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

Sprint

SP

Start

End

1

20

02. Jul

06. Jul

2

27

09. Jul

13. Jul

3

33

16. Jul

20. Jul

4

39

23. Jul

27. Jul

5

40

30. Jul

03. Aug

6

44

06. Aug

10. Aug

 

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. 

Die App für scaled agile Teams ist da!

Scrum Velocity: Die Wirklichkeit sieht doch oft so aus

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 Sprint: Warum 1 Woche effektiver ist

Warum ein 1-wöchiger Sprint viel effektiver ist und die Velocity Ihres Teams enorm steigern kann, erfahren Sie hier.

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.

Story #

Sprint assigned

Sprint closed

SP

Closed

1

1

1

5

03. Jul

2

1

1

8

06. Jul

3

1

1

2

04. Jul

4

1

1

2

04. Jul

5

1

1

3

05. Jul

6

2

2

13

12. Jul

7

2

2

2

10. Jul

8

2

2

2

12. Jul

9

2

3

5

17. Jul

10

2

3

5

17. Jul

11

3

3

20

20. Jul

12

3

3

8

17. Jul

13

3

3

5

18. Jul

14

4

4

13

26. Jul

15

4

4

5

24. Jul

16

4

4

8

24. Jul

17

4

4

13

27. Jul

18

5

5

20

02. Aug

19

5

6

20

08. Aug

20

6

6

13

07. Aug

21

6

6

5

08. Aug

22

6

6

5

08. Aug

23

6

6

8

09. Aug

24

6

6

8

10. Aug

25

6

6

5

10. Aug

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.

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

Agile Transformation: Ziele & Metrics

Agile Transformation Ziele & Metrics – Damit Ihre Agile Transformation nicht scheitert, sollten Sie unbedingt Ziele definieren – aber vor allem messen! Wie und welche, erfahren Sie hier.

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.

Bist du Scrum Master, Agile Coach
oder Product Owner?

Unser Team aus erfahrenen und zertifizierten Agile Expert:innen entwickelt kontinuierlich praxiserprobte Strategien und Methoden, um agile Prozesse zu optimieren und mit den täglichen Herausforderungen besser umgehen zu können.

Diese Erkenntnisse möchten wir dir nicht vorenthalten!
Schau gerne hier vorbei:

Klicke, um Artikel mit den gleichen Tags zu zeigen:

Klaus Riedel
Als agile Coach begleitete Klaus Riedel mit seinem Team die digitale Transformation und die Einführung von Scrum und SAFe in großen Organisationen wie Deutsche Bank, Conrad Electronics, Volkswagen, PWC und anderen.

Alle seine gewonnenen praktischen Erfahrungen in mehr als 15 Jahren agile Transformation sind in die Artikel seines Blogs eingeflossen.

In der Scagile Academy bildet er Nachwuchs Agile Experts aus und seit 2016 unterrichtet er agiles Projektmanagement an der deutschen Fakultät der TU Sofia.

Mehr interessante Artikel für dich:

Dein kostenloses Velocity Excel Template

Wir senden dir dein kostenloses Velocity Excel Template per Email zu. Gebe dazu bitte hier deine Kontaktdaten ein.

WSJF Excel Template | scagile