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

Geschwindigkeit in Scrum hilft Ihnen, die Geschwindigkeit zu bestimmen, mit der das Scrum-Team Aufgaben erledigt. Wir können es als die durchschnittliche Anzahl von Story Points definieren, die in einem Sprint abgeschlossen wurden. Velocity kann auch die Dauer eines Projekts anhand des bereits abgeschlossenen Arbeitsfortschritts abschätzen. Dies ist jedoch nur für ein reifes Team sinnvoll, das in einem gleichmäßigen und stetigen Tempo arbeitet. Sehen Sie sich an, was Velocity ist und wie Sie es am besten für sich nutzen können!

Geschwindigkeit in Scrum – Inhaltsverzeichnis:

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

Geschwindigkeit in Scrum – Einführung

Geschwindigkeit ist eine optionale, aber beliebte Methode, um das Tempo eines Scrum-Teams zu messen. Dies liegt daran, dass eine genau geschätzte Geschwindigkeit es ermöglicht, die Zeit, die zum Abschluss eines Projekts benötigt wird, in angemessenem Umfang vorherzusagen. Es ist jedoch eine Maßnahme, die nur auf ein bestimmtes Entwicklungsteam angewendet werden kann, das Aufgaben erledigt, die es selbst „bewertet“ hat, indem es eine vertraute Einheit wie beispielsweise Story Points verwendet.

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

Tatsächliche und geplante Geschwindigkeit

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

Die geplante Velocity hingegen wird basierend auf einem Durchschnittswert der tatsächlichen Velocity geschätzt. Es erfordert die Annahme, dass sich das Entwicklungsteam nicht ändert. Es ist ein wichtiges internes Instrument für das Entwicklungsteam, das darauf basierend beurteilen kann, ob die Zusammenarbeit im Team gut läuft und ob das Arbeitstempo beibehalten wird.

Planned Velocity ermöglicht es dem Product Owner auch, die Ausführungszeit genau definierter User Storys zu prognostizieren, die für die Ausführung in nachfolgenden Sprints geplant sind. Dies ermöglicht eine effizientere Pflege des Product Backlogs, über das wir in diesem Artikel geschrieben haben. Die Anwendung der geplanten Velocity zur Schätzung der Projektdauer ist jedoch nicht so einfach.

Schwierigkeiten und Risiken im Zusammenhang mit Velocity in Scrum

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

• Schätzen größerer Gesamtheiten oder des gesamten Projekts – während das Entwicklungsteam die Anzahl der Story Points, die einer bestimmten Aufgabe zugewiesen werden sollen, genau abschätzen kann, ist es sehr schwierig oder unmöglich, größere Gesamtheiten für die zukünftige Implementierung in diesen Einheiten zu beschreiben
• Änderungen im Projekt – Jede Änderung im Projekt bedeutet möglicherweise eine Änderung der Anzahl der Story Points, die zum Erreichen des Produktziels erforderlich sind. Es kann auch sein, dass bereits abgeschlossene Aufgaben geändert oder gar nicht in der endgültigen Version des Produkts verwendet werden müssen
• Unvorhergesehene Ereignisse – die Vorhersage des Tempos zukünftiger Projekte auf der Grundlage bereits abgeschlossener Projekte, d. h. die Umrechnung der tatsächlichen Geschwindigkeit in die geplante Geschwindigkeit, kann zu genauen Schätzungen führen. Allerdings hat jedes Projekt seine Eigenheiten und eine genaue Vorhersage anhand der Historie ist meist nicht möglich.

Zusammenfassung

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

Velocity in 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 bestimmen kann, wie viele Aufgaben es während eines einzelnen Sprints erledigen kann.

Velocity in den Händen des Product Owners wird zu einem nützlichen Werkzeug, um die Frist für größere Aufgaben abzuschätzen.

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 bewussten Überschätzung seines Werts zur Verbesserung der externen Bewertung der Arbeit des Scrum-Teams führen kann.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Alle Beiträge anzeigen

Scrum-Leitfaden:

1. Glossar der Grundbegriffe, Rollen und Begriffe
2. Was ist Scrum?
3. Scrum-Werte
4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
5. Scrum Team – was ist das und wie funktioniert es?
6. Wer ist ein Product Owner?
7. Die häufigsten Fehler des Product Owners
8. Wer ist der Scrum-Master?
9. Eigenschaften eines guten Scrum Masters
10. Die häufigsten Fehler des Scrum Masters
11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
12. Zusammenarbeit zwischen Product Owner und Scrum Master
13. Entwicklungsteam in Scrum
14. Die häufigsten Fehler von Entwicklern
15. Scrum-Artefakte
16. Scrum skalieren
17. Sprint-Rückstand
18. Was ist das Product Backlog?
19. Was sind User Stories?
20. Erstellen Sie die beste User Story mit INVEST
21. Die häufigsten Fehler in User Storys
22. Akzeptanzkriterien für User Storys
23. Schätzung und Story Points in Scrum
24. Planungspoker
25. Team-Schätzspiel
26. Inkrement definieren
27. Scrum-Ereignisse
28. Was ist Sprint in Scrum?
29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
30. Was ist ein Burndown-Diagramm?
31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
32. Vor- und Nachteile des Burndown-Charts
33. Kanban-Boards in Scrum und Scrumban
34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
35. Tägliches Scrum
36. Sprint-Planung
37. Sprint-Review
38. Was ist eine Sprint-Retrospektive?
39. Häufige Fehler während einer Sprint-Retrospektive
40. Pflege des Produkt-Backlogs