Scrum-Leitfaden | 34. Geschwindigkeit im Scrum – Geschwindigkeit des Entwicklungsteams

Die Velocity im Scrum hilft Ihnen, die Rate zu bestimmen, mit der das Scrum-Team Aufgaben abschließt. Wir können sie als die durchschnittliche Anzahl von Story Points definieren, die in einem Sprint abgeschlossen werden. Die Velocity kann auch die Dauer eines Projekts basierend auf bereits abgeschlossenem Arbeitsfortschritt schätzen. Dies macht jedoch nur Sinn für ein reifes Team, das in einem gleichmäßigen und stetigen Tempo arbeitet. Werfen Sie einen Blick darauf, was Velocity ist und wie Sie es am besten für sich nutzen können!

Velocity im Scrum – Inhaltsverzeichnis:

1. Velocity im Scrum – Einführung
2. Tatsächliche und geplante Velocity
3. Schwierigkeiten und Risiken im Zusammenhang mit Velocity im Scrum
4. Zusammenfassung

Velocity im Scrum – Einführung

Velocity ist eine optionale, aber beliebte Methode zur Messung des Tempos eines Scrum-Teams. Dies liegt daran, dass eine genau geschätzte Velocity es ermöglicht, in angemessenem Umfang die benötigte Zeit zur Fertigstellung eines Projekts vorherzusagen. Es handelt sich jedoch um ein Maß, das nur auf ein bestimmtes Entwicklungsteam angewendet werden kann, das Aufgaben ausführt, die es selbst mit einer vertrauten Einheit, wie zum Beispiel Story Points, “bewertet” hat.

Die Velocity des Entwicklungsteams wird am häufigsten in Form eines Velocity-Diagramms dargestellt. Auf der X-Achse sind aufeinanderfolgende Sprints markiert. Auf der Y-Achse hingegen finden wir die Anzahl der Story Points oder andere entsprechende Einheiten, die in einem bestimmten Sprint abgeschlossen wurden. Mit dem Velocity-Diagramm erhält das Scrum-Team einen klaren Überblick über Veränderungen im Tempo seiner Arbeit. Wenn die auf dem Diagramm markierte Linie steigt, bedeutet dies, dass das Team seine Effizienz optimiert oder den Wert der Story Points reduziert. Sowohl der Scrum Master als auch der Product Owner sollten daher die Linie, die die Velocity des Teams zeigt, sorgfältig verfolgen.

Tatsächliche und geplante Velocity

Die tatsächliche Velocity des Entwicklungsteams beschreibt das Arbeitstempo im abgeschlossenen Sprint und wird am Ende jedes Sprints berechnet. Sie nimmt den Wert der Summe der Story Points für alle abgeschlossenen User Stories an. Die tatsächliche Velocity des Entwicklungsteams ermöglicht es, mit einer gewissen Wahrscheinlichkeit das Tempo zukünftiger Aufgaben zu planen und zu schätzen.

Die geplante Velocity hingegen wird basierend auf einem Durchschnittswert der tatsächlichen Velocity geschätzt. Sie erfordert die Annahme, dass es keine Veränderungen im Entwicklungsteam gibt. Sie ist ein wichtiges internes Werkzeug für das Entwicklungsteam, das auf dieser Grundlage beurteilen kann, ob die Zusammenarbeit im Team gut verläuft und ob das Arbeitstempo aufrechterhalten wird.

Die geplante Velocity ermöglicht es auch dem Product Owner, die Ausführungszeit gut definierter User Stories, die für die Ausführung in den folgenden Sprints geplant sind, vorherzusagen. Dies ermöglicht eine effizientere Pflege des Product Backlogs, über die wir in diesem Artikel geschrieben haben. Die Praxis, die geplante Velocity zur Schätzung der Projektdauer zu verwenden, ist jedoch nicht so einfach.

Schwierigkeiten und Risiken im Zusammenhang mit Velocity im Scrum

Velocity im Scrum wird oft zu viel Bedeutung beigemessen, ohne die folgenden Faktoren zu berücksichtigen:

• Schätzung größerer Ganzheiten oder des gesamten Projekts – während das Entwicklungsteam die Anzahl der Story Points, die einer bestimmten Aufgabe zugewiesen werden sollen, genau schätzen kann, ist es sehr schwierig oder unmöglich, größere Ganzheiten für die zukünftige Umsetzung in diesen Einheiten zu beschreiben
• Änderungen im Projekt – jede Änderung im Projekt bedeutet potenziell eine Änderung der Anzahl der Story Points, die benötigt werden, um das Produktziel zu erreichen. Es kann auch sein, dass bereits abgeschlossene Aufgaben modifiziert oder sogar in der endgültigen Version des Produkts nicht verwendet werden müssen
• Unvorhergesehene Ereignisse – die Vorhersage des Tempos zukünftiger Projekte basierend auf bereits abgeschlossenen, das heißt, die tatsächliche Velocity in geplante Velocity zu übersetzen, kann zu genauen Schätzungen führen. Allerdings hat jedes Projekt seine Besonderheiten, und eine genaue Vorhersage basierend auf der Geschichte ist in der Regel unmöglich.

Zusammenfassung

Die Verwendung von Velocity als Metrik zur Bewertung der Effektivität des Entwicklungsteams kann dazu führen, dass ihre Zuverlässigkeit abnimmt. Sie kann auch die Qualität der Schätzungen beeinträchtigen, über die wir ausführlicher in diesem Artikel geschrieben haben. Schließlich kann das Entwicklungsteam, um die bestmöglichen Ergebnisse in den Metriken zu erzielen, die Arbeitsintensität der Aufgaben überschätzen, um die Velocity zu erhöhen. Dies ist nachteilig, da das Team selbst wertvolle Informationen verliert, um Verbesserungen vorzunehmen und seine Aufgaben genauer zu planen.

Velocity im Scrum ist in erster Linie als internes Maß nützlich, das vom Entwicklungsteam verwendet wird, um das Tempo seiner Arbeit zu bewerten. Dies liegt daran, dass es ihm ermöglicht, zu bestimmen, wie viele Aufgaben es während eines einzelnen Sprints abschließen kann.

Velocity wird in den Händen des Product Owners zu einem nützlichen Werkzeug zur Schätzung der Frist für größere Aufgaben.

Die größten Risiken sind jedoch mit der Verwendung von Velocity als Metrik zur Bewertung des Entwicklungsteams verbunden. Dies liegt daran, dass es zu einer Verringerung seiner Glaubwürdigkeit und sogar zu einer absichtlichen Überschätzung seines Wertes führen kann, um die externe Bewertung der Arbeit des Scrum-Teams zu verbessern.

Wenn Ihnen unsere Inhalte gefallen, treten Sie unserer aktiven Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.