Ungefähre Lesedauer: 2 Minuten

Errechnen der Velocity

Auf diese Weise kann man die Arbeitsgeschwindigkeit (Velocity) eines Scrum Teams errechnen.

Normalerweise definiere ich Velocity einfach nur als Maßeinheit für die Schnelligkeit eines Teams. In den meisten Fällen funktioniert diese Definition auch recht gut. Wenn man aber genauer darüber nachdenkt, was alles bei der Berechnung der Velocity einbezogen werden muss, reicht diese Definition nicht mehr aus.

 

 

Es gibt eigentlich zwei Arten, die Velocity zu definieren:

  1. Mit der Velocity kann gemessen werden, wie viel Funktionalität ein Team in einem Sprint liefern kann.
  2. Mit der Velocity kann gemessen werden, wie gut ein Team während eines Sprints Ideen in neue Funktionalität umwandeln kann.

Diese beiden Definitionen scheinen auf den ersten Blick das Gleiche auszusagen – tun sie aber nicht.

Ein Beispiel

Um den Unterschied erkennen zu können, stellen Sie sich folgendes Szenario vor:

Sie springen in einen Fluss und schwimmen los. Nach einer Stunde sind Sie zwei Kilometer von Ihrem Startpunkt entfernt. Ihre Velocity ist nun scheinbar zwei Kilometer pro Stunde (bzw. pro Sprint).

Aber was, wenn der Fluss mit einer Geschwindigkeit von einem Kilometer pro Stunde fließt und Sie gegen den Strom geschwommen sind? Dann sind Sie in Wirklichkeit drei Kilometer geschwommen. Auch wenn Sie eine messbare Distanz von zwei Kilometern zurückgelegt haben, mussten Sie quasi drei Kilometer schwimmen, um diese zwei Kilometer überwinden zu können.

Ist Ihre Velocity nun zwei oder drei? Wenn wir von der ersten Definition ausgehen, ist es zwei. Sie sind ja zwei Kilometer weit gekommen.

Bei der zweiten Definition wäre die Antwort drei. Immerhin haben Sie die Fähigkeit, innerhalb eines Sprints drei Kilometer weit zu kommen. Würden Sie in einem Gewässer ohne Strömung schwimmen, könnte man das erkennen.

Sollte ein Team in einem agilen Projekt nun beispielsweise auch das Fixen von Bugs bei der Velocity angerechnet bekommen? Ein Team, das nur misst, wie viel Funktionalität es in einem Sprint liefern kann, wird das nicht berücksichtigen. Es wurde keine neue Funktionalität geliefert, also kann man sich damit auch keine Punkte verdienen.

Anders ist das jedoch bei der zweiten Definition von Velocity. Die Logik dahinter ist nämlich, dass die Zeit auch für das Hinzufügen neuer Funktionalität hätte genutzt werden können. Allerdings hielt der Product Owner andere Arbeiten für wichtiger.

Bei den meisten Teams ist das Resultat bei beiden Definitionen identisch. Größere Unterschiede gibt es jedoch bei Teams, die viele Arbeiten erledigen, die sie nicht bei der Berechnung der Velocity miteinbeziehen (z. B. Bugfixing oder Refactoring).

Welche Definition ist besser?

Keine der beiden Definitionen ist grundsätzlich besser als die andere. Nach welcher man sich richtet, sollte hauptsächlich davon abhängen, was man sich von der Berechnung der Velocity erhofft und wie die Zukunft aussehen wird.

Wenn in Zukunft wahrscheinlich alles genau so sein wird, wie bisher, dann ist die erste Definition die beste. Beispielsweise, wenn das Team weiterhin gleich viel Zeit für das Fixen von Bugs und Refactoring aufbringen wird.

Wenn es zukünftig aber Änderungen gibt, z. B. dass die Zeit bald für ganz andere Arbeiten genutzt wird, ist die zweite Definition zu bevorzugen. Dann ist es besser, die Points für diese Aktivitäten auch bei der Berechnung der Velocity einzukalkulieren.

Die Hauptsache ist, dass mit allen Teammitgliedern, dem Product Owner und dem Scrum Master abgeklärt wird, was genau “Velocity” für das Team bedeutet. Eine klare Definition macht es nämlich wesentlich leichter, zu beantworten, was alles bei der Berechnung der Velocity einbezogen werden soll und was nicht.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

 

 Sie wollen mehr erfahren? Besuchen Sie unsere Trainings  Zu den Trainings
Das könnte dich auch interessieren

Unfertige Arbeiten sind nichts Schlimmes Vor einiger Zeit habe ich bereits darüber geschrieben, dass es für ein erfahrenes Team ab und zu in Ordnung sein kann, auch unfertige Arbeit...
Keine Notizen im Daily Scrum Machen Sie sich Notizen im Daily Scrum? Als ich vor einigen Jahren als Berater in einem Unternehmen war, wurde ich gebeten, mir dort als E...
User Stories mit 0 Punkten im Product Backlog? User Stories mit 0 Punkten bedeuten normalerweise so gut wie keinen Aufwand Ab und zu werde ich gefragt, welchen Nutzen User Stories mit...