3 Fehler, die Scrum-Teams bei der Verwendung von Velocity vermeiden sollten und wie sie stattdessen Performance, Prognosesicherheit und Wert messen können

Hochperformante Teams, die vorhersagbar liefern, tragen maßgeblich zum Erfolg von Unternehmen bei.

Solche Teams versprechen sich Unternehmen, die Scrum einführen. Leider überprüfen Organisationen dieses Versprechen häufig nur auf der Grundlage von Velocity. Der 15. State of Agility Report untermauert meinen Eindruck; dort sehen 45 % aller Befragten Velocity als ein Maß für Agilität.

Velocity ist eine hilfreiche Metrik und gleichzeitig eine Quelle für Fehler. Als Professional Scrum Trainer begegnen mir diese drei Fehler immer wieder:

1. Verwendung von Velocity, um die Teamleistung zu vergleichen

In meinem Professional Agile Leadership-Training fragen Teamleiter immer wieder, wie man die Performance von Teams mit Hilfe von Velocity vergleichen kann. Die vorherrschende Meinung ist, dass dies sinnvoll und möglich sei. Man müsse es nur schaffen, die Velocity über Teams hinweg zu normalisieren. In meiner Arbeit als Scrum Master bin ich schon auf unterschiedliche solcher Versuche gestoßen. Beispielsweise wurde die Anzahl der erledigten Story Points in einem Sprint durch die Zahl der Entwickler im Team geteilt. Oder es wurde vom Management festgelegt, dass ein Story Point nicht mehr als einen Tag an Entwicklungsarbeit entsprechen darf. Beide Herangehensweisen haben eines gemeinsam: Sie führen die Idee von Story Points ad absurdum. Diese sollen Komplexität in einer eigenen Größeneinheit (“Story Point”) ausdrücken. Die Arbeitszeit ist beispielsweise kein Maß der Komplexität, sondern der Zeit. (Siehe hierzu auch mein Beitrag „Warum Story Points nicht geeignet sind, um Releasedaten vorherzusagen”)

Es ist nicht im Sinn des Erfinders, die Velocity über Teamgrenzen hinweg normalisieren zu wollen, da es sich bewusst um eine teaminterne Messgröße handelt. Sie drückt die Menge des Product Backlogs aus, die während eines Sprints von einem Scrum-Team in ein Produktinkrement umgewandelt wird.

Will man die Performance von Teams messen, muss man erst verstehen, dass sich die Performance eines Teams ausschließlich im erbrachten Wert für den Kunden und das Unternehmen ausdrücken lässt.

Um den Wert, den ein Team liefert, zu bestimmen, muss man eine ganzheitliche Sicht einnehmen, denn Wert ist nicht nur gleich Umsatz.

Eine ganzheitliche Wertbetrachtung umfasst:

  • Den aktuellen Wert, den das Team stiftet, zum Beispiel in Kundenzufriedenheit oder Umsatz ausgedrückt.
  • Den potentiellen Wert, der noch möglich ist, zum Beispiel in Marktanteilen oder der Differenz zwischen der gewünschten und der tatsächlichen Erfahrung eines Nutzer bei der Verwendung des Produkts.
  • Die Fähigkeit, auf Veränderungen zu reagieren, zum Beispiel die Release-Häufigkeit oder die Zeitspanne von der Entstehung einer Idee bis zu dem Zeitpunkt, ab dem der Kunde tatsächlich einen Nutzen aus dieser Idee zieht.
  • Die Innovationsfähigkeit, zum Beispiel das Verhältnis von Neuentwicklungen zu Defektbehebung.

2. Verwendung von Velocity, um das Verhältnis zwischen prognostizierter Arbeit und erledigter Arbeit zu messen

Obwohl wir uns nicht mehr im industriellen Zeitalter befinden, sondern im digitalen Zeitalter, ist das industrielle Mindset oft noch tief verwurzelt. Der Irrglaube, dass sich Produktentwicklung durch Vorhersage der Kundenwünsche, minutiöser Planung der Umsetzung und sturer Abarbeitung beherrschen lässt, hält sich weiterhin hartnäckig.

Velocity hilft Scrum-Teams, ihren Sprint zu planen und sie kann verwendet werden, um mögliche Release-Daten zu prognostizieren. Sie sollte niemals genutzt werden, um die Prognosesicherheit zu messen.

Einen Release-Termin und einen Release-Umfang vorzugeben, daraus die benötigte Velocity auszurechnen und den Fortschritt eines Scrum-Teams daran zu messen, wie das Verhältnis zwischen prognostizierter und erledigter Arbeit ist, gaukelt Sicherheit vor, welche die Realität von komplexer Arbeit ausblendet. Fortschritt lässt sich nur in lieferfähigen Versionen des Produkts messen und nicht dadurch, wie gut der ursprünglich gefasste Plan eingehalten wird. Das Prinzip, dass funktionierende Software, das wichtigste Fortschrittsmaß ist, ist so grundlegend, dass es auch ins Manifest für agile Softwareentwicklung aufgenommen wurde.

Die Grundlage für mögliche Vorhersagen bildet eine nutzbare Version des Produkts, also für einen Nutzer verwendbares Produkt, dass keinerlei weitere Arbeit mehr verlangt. Nur diese stellt die glaubhafte Sicherheit her, dass wirklich Fortschritt erzielt wurde. Denn alles, was bis jetzt fertiggestellt wurde, kann nun jederzeit ausgeliefert werden. Basierend auf dieser Transparenz, können nun mithilfe der Velocity, der vergangen Sprints, mögliche Release-Termine prognostiziert werden.

Release Burndown
Release-Burndown, um Release-Termine zu prognostizieren. Bild von ReQtest.

3. Verwendung von Velocity als Maß für Output oder Wert

Velocity liefert keine Aussage, wieviel Output, d.h. die Anzahl der fertiggestellten Product-Backlog-Einträge, ein Team liefert.

Ein Scrum-Team mit einer Velocity von 20 liefert möglicherweise weniger Einträge als ein Scrum-Team mit einer Velocity von 10. Teams, deren durchschnittliche Product-Backlog-Einträge die Größe 8 haben, liefern wahrscheinlich weniger als Teams, deren durchschnittlicher Product-Backlog-Einträge die Größe 21 haben. Verwendet ein Scrum-Team die Fibonacci Zahlen bis 21 als Größenskala, wird es eine niedrigere Velocity haben, als ein Scrum-Team, welches Planning-Poker-Zahlen bis 100 verwendet. Da die Velocity eines Teams von der verwendeten Schätzmethode und dessen zugrunde liegender Größenskala abhängt, ist Velocity kein Maß, den Output eines Teams zu bestimmen.

Velocity liefert auch keine Aussage, wie viel Wert ein Team mit seiner Arbeit stiftet.

Features können fertiggestellt und ausgeliefert werden und “perfekt funktionieren”, aber trotzdem keinen Wert für den Nutzer liefern. Ein Beispiel hierfür sind Pop-up-Fenster auf Websites. Sie sollen uns Nutzer dazu bringen, dass wir uns in die Mailingliste eines Unternehmens eintragen. Technisch gesehen funktionieren sie wie vorgeschrieben. Da allerdings immer weniger Websites Pop-up Fenster haben, hat sich wohl herausgestellt, dass sie kaum Mehrwert für den Nutzer liefern. Stattdessen sind wir lediglich genervt und verlassen die Seite.

Eine hohe Velocity eines Teams sollte nicht mit einem hohen erzeugten Wert für das Unternehmen gleichsetzen werden.

Wenn wir messen wollen, welchen Wert ein Scrum-Team wirklich liefert, sollten der Fokus uns auf wertgenerierenden Zielen für Teams liegen. Ein guter Ausgangspunkt bietet ein Sprint- oder Produkt-Ziel, das einen Outcome für einen Nutzer oder Kunden ermöglicht.

Ein einfaches Template, solche Ziele zu formulieren, lautet:

Wir glauben, dass [Geschäftsergebnis] erreicht wird, wenn [Nutzer] folgenden [Outcome] erreicht.

Ein Outcome hat nichts mit der Umsetzung von Features zu tun. Natürlich werden häufig durch die Entwicklung der richtigen Features Outcomes erzielt. Stattdessen beschreibt ein Outcome eine beobachtbare und messbare Veränderung im menschlichen Verhalten, die zu Geschäftsergebnissen führt. Das Verhalten von Kunden, Nutzern oder Mitarbeitern, die zu guten Ergebnissen des Unternehmens führen, sollten satt Velocity im Mittelpunkt der Arbeit von Scrum-Teams stehen.

Die Arbeit zu schätzen, bevor sie erledigt wird, ist die Realität vieler Scrum-Teams. Velocity ist eine hilfreiche Praktik, um im Sprint Planning die Arbeit zu planen und im Sprint Review mögliche Release-Daten zu prognostizieren. Für alles, was darüber hinausgeht, gibt es geeignetere Praktiken.

Hilfreiche Trainings zum Thema Metriken mit PST Simon Flossmann

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert