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 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 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.

Download

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 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 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:

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

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 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. 

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 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.

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.

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.

Download