In der Landschaft der agilen und Scrum-Methodologien erzeugen wenige Konzepte so viel Verwirrung und Angst wieGeschwindigkeit. Oft wird sie von Führungskräften als Leistungsabrechnung oder von Teams als starres Ziel behandelt, wodurch das ursprüngliche Ziel des Metrics häufig verfehlt wird. Geschwindigkeit ist ein Werkzeug für das Team, kein Peitschenknall für den Manager. Wenn sie richtig verstanden wird, bietet sie Einblicke in die Kapazität und Vorhersagbarkeit. Wenn sie missverstanden wird, verfälscht sie das Verhalten und schädigt das Vertrauen.
Dieser Leitfaden untersucht die wahre Natur der Geschwindigkeit, wie sie innerhalb eines Scrum-Rahmenwerks funktioniert, und die entscheidenden Grenzen, die sie gesund halten. Wir werden die technischen Definitionen, die häufigen Fallen, die zu Missdeutungen führen, sowie die Strategien zur Nutzung von Daten zur Verbesserung des Flows ohne die psychologische Sicherheit zu gefährden, beleuchten.
🧩 Was ist Geschwindigkeit im Scrum?
Im Kern ist die Geschwindigkeit eine Messung der Menge an Arbeit, die ein Scrum-Team in einem einzelnen Sprint bewältigen kann. Sie ist keine Messung der Geschwindigkeit im herkömmlichen Sinne, noch ein universeller Maßstab für Produktivität. Stattdessen ist sie eine relative Maßeinheit, die aus der eigenen historischen Leistung des Teams abgeleitet wird.
- Sie ist rückblickend: Sie wird auf Basis der in vergangenen Sprints abgeschlossenen Arbeit berechnet.
- Sie ist teambezogen: Sie spiegelt die einzigartige Kapazität, das Fähigkeitsprofil und den Kontext einer bestimmten Gruppe wider.
- Sie ist eine Planungshilfe: Ihr primärer Zweck ist es, dem Team zu helfen, vorherzusagen, wie viel Arbeit es zukünftig übernehmen kann.
Die Geschwindigkeit wirkt als Stabilisator. Im Laufe der Zeit neigt die Geschwindigkeitszahl dazu, sich zu stabilisieren, wenn ein Team Konsistenz in seiner Definition des Fertiggestellten und in seinen Schätzmethoden beibehält. Diese Stabilität ermöglicht eine bessere Produktprognose. Allerdings erzeugt die Behandlung dieser Zahl als festes Ziel Spannungen.
⚙️ Wie wird die Geschwindigkeit berechnet?
Das Verständnis der Berechnungsmechanik ist entscheidend, um die Grenzen des Metrics zu erkennen. Die Geschwindigkeit wird typischerweise mithilfe vonStory Points. Story Points sind eine relative Schätzmethode, die verwendet wird, um den Aufwand, die Komplexität und das Risiko einer Benutzerstory einzuschätzen.
Die Formel
Die Berechnung ist einfach, doch die Eingaben erfordern Disziplin:
- Identifizieren Sie alle Benutzerstories, die im Sprint abgeschlossen wurden.
- Stellen Sie sicher, dass die Definition des Fertiggestellten (DoD) für jedes Element erfüllt wurde.
- Addieren Sie die Story Points, die den abgeschlossenen Elementen zugewiesen wurden.
- Die resultierende Summe ist die Geschwindigkeit für diesen Sprint.
Wichtig ist, dass Arbeit, die begonnen, aber nicht abgeschlossen wurde, nicht zählt. Arbeit, die erst spät hinzugefügt und dann abgeschlossen wurde, zählt hingegen. Diese Unterscheidung ist entscheidend für die Gewährleistung der Genauigkeit.
- Abgeschlossene Arbeit: Nur Elemente, die die Akzeptanzkriterien vollständig erfüllen, tragen zur Bewertung bei.
- Teilweise abgeschlossene Arbeit: Halbabgeschlossene Geschichten werden bei der Berechnung ignoriert.
- Spikes Time-boxierte Forschungsspitzen zählen normalerweise nicht zur Geschwindigkeit, es sei denn, sie ergeben einen lieferbaren Increment.
- Technische Schuld: Refactoring-Aufgaben tragen zur Geschwindigkeit bei, wenn sie die Definition des fertigen Zustands erfüllen, müssen aber gegenüber Feature-Arbeit abgewogen werden.
🚫 Häufige Missbrauchsmuster der Geschwindigkeit
Die Gefahr liegt nicht in der Metrik selbst, sondern darin, wie sie von externen Stakeholdern angewendet wird. Wenn die Geschwindigkeit aus ihrem Kontext gerissen wird, wird sie zu einer Quelle von Druck statt zu einem Planungswerkzeug. Nachfolgend sind die häufigsten Weisen aufgeführt, wie diese Metrik missbraucht wird.
1. Vergleich von Teams
Einer der schädlichsten Fehler ist der Vergleich der Geschwindigkeit von Team A mit der von Team B. Dieser Vergleich ist grundlegend fehlerhaft, weil:
- Schätzskalen unterscheiden sich: Team A könnte eine Geschichte als 5 Punkte schätzen, während Team B dieselbe Geschichte aufgrund ihrer eigenen Kalibrierung als 8 Punkte bewertet.
- Die Komplexität variiert: Ein Team könnte an einem veralteten System mit hoher technischer Schuld arbeiten, während ein anderes Team an einem Neubauprojekt arbeitet.
- Teamzusammensetzung: Ein Team mit einem Senior-Architekten verhält sich anders als ein Team aus Junior-Entwicklern.
Die Bewertung von Teams nach Geschwindigkeit fördert interne Konkurrenz und hemmt die Zusammenarbeit. Es suggeriert, dass höhere Zahlen besser sind, was die Inflation von Punkten fördert.
2. Setzen von Zielen
Management versucht oft, Geschwindigkeitsziele festzulegen, beispielsweise „Wir brauchen 40 Punkte pro Sprint“. Dadurch wird eine beschreibende Metrik zu einem vorgeschriebenen Ziel. Wenn die Geschwindigkeit zu einem Ziel wird, treten folgende Verhaltensweisen auf:
- Aufblähen der Schätzungen: Teammitglieder könnten die Story-Punkte aufblähen, um sicherzustellen, dass das Ziel erreicht wird.
- Reduzierung des Umfangs: Teams könnten Funktionen in kleinere Teile aufteilen, um die Anzahl künstlich zu erhöhen.
- Qualität wird opfern: Der Fokus verschiebt sich von der Wertlieferung hin zum Erreichen der Zahl, was möglicherweise das Auslassen von Tests oder Dokumentationen zur Folge hat.
3. Vorhersage von Terminen für Stakeholder
Die Geschwindigkeit zu nutzen, um einem Kunden auf Basis der Leistung eines einzelnen Sprints ein konkretes Release-Datum zu versprechen, ist riskant. Die Geschwindigkeit schwankt. Ein Team könnte einen langsamen Sprint aufgrund von Feiertagen, Krankheit oder unvorhergesehenen technischen Blockaden haben. Die Verwendung eines einzigen Datenpunkts, um ein Datum festzulegen, erzeugt unrealistische Erwartungen.
4. Messung der individuellen Leistung
Die Geschwindigkeit ist eine Team-Metrik. Ihre Aufteilung auf individuelle Leistung verstößt gegen die Scrum-Prinzipien. Agile basiert auf der fachübergreifenden Zusammenarbeit. Wenn ein Entwickler 5 Punkte und ein anderer 8 Punkte abschließt, führt der Vergleich diese Tatsachen aus der Sicht der Komplexität der Aufgaben und der Abhängigkeiten zwischen ihnen aus.
✅ Korrekte Anwendung der Geschwindigkeit
Wenn sie korrekt verwendet wird, dient die Geschwindigkeit der Selbststeuerung des Teams. Sie ist ein Spiegel, kein Hammer. Hier ist, wie man sie effektiv nutzen kann.
1. Sprint-Planung
Die angemessenste Verwendung der Geschwindigkeit ist in der Sprint-Planung. Indem das Team den Durchschnitt der Geschwindigkeit der letzten drei bis fünf Sprints betrachtet, kann es eine realistische Kapazität für den kommenden Sprint bestimmen.
- Durchschnittsberechnung:Addiere die Punkte der letzten 3-5 Sprints und teile durch die Anzahl der Sprints.
- Verpflichtung:Das Team nimmt Arbeit in den Sprint auf, bis die insgesamt geschätzten Punkte mit diesem Durchschnitt übereinstimmen.
- Puffer:Es ist ratsam, etwas unter dem Durchschnitt zu planen, um Unterbrechungen oder unerwartete Arbeit zu berücksichtigen.
2. Release-Vorhersage
Die Geschwindigkeit hilft bei der Beantwortung der Frage: „Wann wird das Produkt fertig sein?“ Indem man die insgesamt verbleibenden Punkte des Produkt-Backlogs durch die durchschnittliche Geschwindigkeit teilt, kann das Team die Anzahl der Sprints schätzen, die benötigt werden, um die Arbeit abzuschließen.
- Bereich, nicht Datum:Stelle Vorhersagen als Bereich (z. B. „zwischen Sprint 10 und 12“) anstelle eines bestimmten Kalenderdatums dar.
- Regelmäßige Aktualisierungen:Aktualisiere die Vorhersage regelmäßig, wenn neue Informationen auftauchen oder sich der Backlog ändert.
- Transparenz:Teile die Vorhersage offen mit den Stakeholdern, damit sie die Beziehung zwischen Umfang und Zeit verstehen.
3. Erkennen von Trends
Die Verfolgung der Geschwindigkeit über die Zeit kann Gesundheitsindikatoren innerhalb des Teams oder des Prozesses aufzeigen.
- Stetige Abnahmen:Ein stetiger Rückgang könnte auf Überlastung, steigende technische Schulden oder eine Veränderung der Teamzusammensetzung hindeuten.
- Stetige Anstiege:Ein plötzlicher Anstieg könnte darauf hindeuten, dass frühere Schätzungen zu konservativ waren oder dass das Team einen effizienteren Arbeitsablauf gefunden hat.
- Volatilität:Hohe Varianz deutet auf Instabilität im Prozess oder in der Definition von „Fertig“ hin.
📉 Geschwindigkeit gegenüber Kapazität
Es ist entscheidend, zwischen Geschwindigkeit und Kapazität zu unterscheiden. Die Verwechslung dieser beiden führt zu Überverpflichtung.
- Kapazität:Bezieht sich auf die verfügbare Zeit (in Stunden), die ein Team zur Arbeit hat. Dazu gehören Urlaube, Besprechungen und Support-Aufgaben.
- Geschwindigkeit:Bezieht sich auf die Menge der Arbeit (Punkte), die abgeschlossen wurde. Dazu gehören die Geschwindigkeit und Effizienz des Teams.
Ein Team könnte eine hohe Kapazität (viele verfügbare Stunden) haben, aber eine geringe Geschwindigkeit (Schwierigkeiten mit der Komplexität). Umgekehrt könnte ein Team eine geringe Kapazität (viele Besprechungen) haben, aber eine hohe Geschwindigkeit (hohe Effizienz). Die Planung erfordert die Balance beider Faktoren.
| Metrik | Maßeinheit | Hauptzweck | Wer sollte es verwenden |
|---|---|---|---|
| Geschwindigkeit | Story-Punkte | Prognose & Planung | Das Scrum-Team |
| Kapazität | Stunden | Zeitplanbare Verfügbarkeit | Das Scrum-Team und der Scrum Master |
| Burn-Down | Stunden/Punkte | Fortschritt verfolgen | Interessenten & Team |
🧠 Die Psychologie von Metriken
Metriken beeinflussen das Verhalten. Das ist ein grundlegendes Prinzip der Organisationspsychologie. Wenn Sie X messen, optimieren Menschen für X. Wenn die Geschwindigkeit die primäre Messgröße für den Erfolg ist, optimiert das Team für die Geschwindigkeit, nicht für den Wert.
Psychologische Sicherheit
Damit die Geschwindigkeit genau ist, muss das Team sich sicher fühlen, wenn Arbeit blockiert ist oder wenn Schätzungen falsch waren. Wenn ein Team befürchtet, dass eine geringe Geschwindigkeit zu Strafen führen wird, wird es:
- Risiken unterschätzen.
- Hindernisse verbergen.
- Komplexe Aufgaben vermeiden.
Dies führt zur Illusion von Fortschritt. Hohe Geschwindigkeitszahlen in einer Kultur der Angst sind oft ein Zeichen für Dysfunktion, nicht für Effizienz.
Fortwährende Verbesserung
Die Geschwindigkeit sollte in der Retrospektive besprochen werden, aber nicht als KPI. Stattdessen besprechen Sie dieProzessder zur Geschwindigkeit geführt hat.
- Warum war dieser Sprint langsamer als üblich?
- Hatten wir zu viele Unterbrechungen?
- War die Definition von „Fertig“ zu streng oder zu locker?
Indem der Fokus auf den Prozess liegt, verbessert das Team das zugrundeliegende System, das sich im Laufe der Zeit natürlich stabilisiert.
🔄 Umgang mit Variationen und Anomalien
Nicht alle Sprints sind gleich. Schwankungen der Geschwindigkeit sind normal und oft zu erwarten. Das Verständnis dafür, warum diese Schwankungen auftreten, ist entscheidend, um die Daten korrekt zu interpretieren.
1. Teamänderungen
Wenn ein Entwickler geht oder ein neues Mitglied beitritt, wird sich die Geschwindigkeit wahrscheinlich ändern. Ein neues Mitglied hat eine Lernkurve. Es kann länger dauern, Aufgaben abzuschließen, oder es könnte auf unerwartete Weise beitragen. Erwarten Sie keine sofortige Gleichheit mit früheren Werten.
2. Scope Creep
Wenn Stakeholder während eines Sprints zusätzliche Arbeit hinzufügen, kann die Geschwindigkeit sinken, weil das Team weniger Zeit für die verpflichteten Aufgaben hat. Alternativ, wenn das Team die Änderung erfolgreich bewältigt, könnte die Geschwindigkeit stabil bleiben, doch dies birgt das Risiko von Überlastung. Es ist besser, Änderungen am Umfang abzulehnen oder sie in die Backlog zu verlegen.
3. Technische Schuld
Je mehr technische Schuld sich ansammelt, desto häufiger sinkt die Geschwindigkeit, da mehr Aufwand erforderlich ist, um Änderungen vorzunehmen. Dies ist ein Signal dafür, Sprints der Refaktorisierung zu widmen. Die Ignorierung führt zu einem langsamen Leistungsverfall.
📊 Zusammenfassung: Machen und Vermeiden
Um sicherzustellen, dass die Geschwindigkeit ein hilfreiches Werkzeug bleibt, halten Sie sich an die folgenden Richtlinien.
| Machen ✅ | Vermeiden ❌ |
|---|---|
| Verwenden Sie es ausschließlich für interne Planung. | Verwenden Sie es, um Teams zu vergleichen. |
| Berechnen Sie es auf Basis abgeschlossener Arbeit. | Zählen Sie teilweise abgeschlossene Arbeit. |
| Diskutieren Sie Trends in den Retrospektiven. | Setzen Sie es als Leistungsziel. |
| Fokussieren Sie sich auf relative Schätzung. | Fokussieren Sie sich auf Stunden oder individuelle Leistung. |
| Akzeptieren Sie Schwankungen als normal. | Strafen Sie Rückgänge der Geschwindigkeit. |
| Aktualisieren Sie die Backlog regelmäßig. | Sperren Sie den Umfang für längere Zeiträume. |
🚀 Letzte Überlegungen für nachhaltiges Wachstum
Die Geschwindigkeit ist ein Nebenprodukt eines gesunden Systems. Wenn das System gesund ist, stabilisiert sich die Geschwindigkeit. Wenn das System defekt ist, schwankt die Geschwindigkeit stark oder sinkt ab. Das Ziel ist nicht, die Geschwindigkeit zu maximieren; das Ziel ist, die Wertlieferung zu maximieren.
Wenn die Führung versteht, dass die Geschwindigkeit eine Planungseinschränkung ist und kein Produktivitätsmotor, ändert sich die Dynamik. Teams fühlen sich befähigt, ihren eigenen Tempo auf Basis von Beweisen festzulegen. Stakeholder lernen, Erwartungen auf Basis von Spannen statt Versprechen zu managen. Der Fokus kehrt zurück zu der Lieferung von qualitativ hochwertiger Software, die Nutzerprobleme löst.
Denken Sie daran, dass Metriken Werkzeuge zur Inspektion und Anpassung sind. Sie sind nicht Selbstzweck. Halten Sie das Team im Mittelpunkt des Gesprächs. Lassen Sie die Daten Entscheidungen informieren, aber lassen Sie die menschliche Urteilsfähigkeit die Strategie leiten.
🔍 Häufig gestellte Fragen
Kann die Geschwindigkeit unbegrenzt steigen?
Nein. Es gibt physische und kognitive Grenzen dafür, wie viel Arbeit ein Team aufnehmen kann. Mit steigender Komplexität bleibt die Geschwindigkeit oft auf einem Plateau oder sinkt sogar. Ein kontinuierliches Wachstum der Geschwindigkeit deutet meist darauf hin, dass die Schätzungskriterien nachlassen, nicht dass die Produktivität steigt.
Was ist, wenn wir keine Story Points verwenden?
Die Geschwindigkeit kann auch mit anderen Einheiten wie Stunden oder idealen Tagen berechnet werden, Story Points werden jedoch aufgrund ihrer Zeitunabhängigkeit bevorzugt. Unabhängig von der Einheit bleibt das Prinzip gleich: die erledigte Arbeit im Verhältnis zur vergangenen Leistung messen.
Berücksichtigt die Geschwindigkeit Fehler?
Nur wenn die Behebung des Fehlers die Definition von Fertigstellung erfüllt. Wenn die Fehlerbehebung eine neue Aufgabe im Backlog ist, zählen ihre Punkte erst nach Abschluss zur Geschwindigkeit. Wenn es sich um einen Fehler in bereits gelieferten Arbeit handelt, wird er oft als separater Vorfall behandelt.
Wie viele Sprints sollten wir durchschnittlich berücksichtigen?
Mindestens drei Sprints liefern eine Grundlage. Fünf bis zehn Sprints ergeben eine stabilere Trendlinie. Verwenden Sie die aktuellsten Daten, da sie den aktuellen Zustand und Kontext des Teams widerspiegeln.
Durch die Achtung der Feinheiten der Geschwindigkeit können Teams den Fallen einer metrikgesteuerten Führung ausweichen. Die Metrik dient dem Team, nicht umgekehrt. Diese Ausrichtung schafft eine Umgebung, in der Vorhersagbarkeit und Qualität gemeinsam gedeihen können.
