In der Welt der agilen Entwicklung erzeugt kaum ein Maßstab so viel Diskussion wie die Geschwindigkeit. Auf der einen Seite verspricht sie Klarheit: eine vorhersehbare Liefergeschwindigkeit. Auf der anderen Seite gefährdet sie das Wohlbefinden des Teams: ein Werkzeug zur Mikroverwaltung. Wenn sie schlecht umgesetzt wird, verwandelt sich die Verfolgung der Geschwindigkeit von einem hilfreichen Kompass in eine Quelle von Stress. 🛑
Scrum-Teams finden sich oft zwischen dem Bedarf an Vorhersagbarkeit und dem Wunsch nach einem nachhaltigen Tempo wieder. Dieser Leitfaden untersucht, wie die Geschwindigkeit genau verfolgt werden kann, ohne die Teamgesundheit zu gefährden. Wir werden uns mit der Mechanik der Geschwindigkeit, dem psychologischen Einfluss der Messung und der Nutzung von Daten zur Stärkung statt zur Kontrolle beschäftigen.
🧠 Was ist Scrum-Geschwindigkeit eigentlich?
Die Geschwindigkeit ist eine Messung für die Menge an Arbeit, die ein Scrum-Team in einem einzelnen Sprint bewältigen kann. Sie wird berechnet, indem die Story Points aller abgeschlossenen User Stories in einem Sprint addiert werden. Doch das Verständnis der Definition ist nur die halbe Miete. Entscheidend ist das Verständnis des Zwecks.
Die Geschwindigkeit ist keine Messung der individuellen Leistung. Sie ist kein Maßstab, um Teams miteinander zu vergleichen. Sie ist ein Planungswerkzeug, das dem Entwicklungsteam helfen soll, vorherzusagen, wie viel Arbeit sie in zukünftige Sprints übernehmen können. 📊
Wenn Teams die Geschwindigkeit als KPI (Key Performance Indicator) behandeln, verschiebt sich der Fokus von der Wertlieferung hin zum Erreichen einer Zahl. Genau hier beginnt die Überlastung. Um dies zu vermeiden, muss das Team die Geschwindigkeit als eine private Kennzahl zurückgewinnen, die ausschließlich dem Entwicklungsteam gehört.
⚖️ Der Zusammenhang mit Überlastung: Warum die Geschwindigkeit schadet
Viele Organisationen missbrauchen Geschwindigkeitsdaten. Die Führung könnte sich die Geschwindigkeit eines Teams ansehen und fragen: „Warum haben wir letztes Monat nur 30 Punkte abgeschlossen? Dieses Monat brauchen wir 40.“ Diese externe Druck erzeugt eine toxische Umgebung.
Wenn die Geschwindigkeit zur Beurteilung der Produktivität verwendet wird, treten mehrere negative Verhaltensweisen auf:
- Überverpflichtung:Teams versprechen mehr Arbeit, als sie bewältigen können, um Stakeholder zu beeindrucken.
- Abschätzung mit Puffer:Entwickler erhöhen die Story Points, um einen Sicherheitspuffer zu schaffen, was die Genauigkeit des Maßstabs verringert.
- Komplexität ignorieren:Einfache Aufgaben werden komplexen, wertvollen Arbeiten vorgezogen, um die Zahlen zu verbessern.
- Qualitätsvernachlässigung:Technische Schulden werden ignoriert, weil sie nicht zur unmittelbaren Geschwindigkeitszahl beitragen.
Diese Umgebung führt zu Erschöpfung. Entwickler kümmern sich nicht mehr um die Qualität des Codes und konzentrieren sich ausschließlich auf das Schließen von Tickets. Das ist die Definition von Überlastung. Um dies zu verhindern, muss die Geschwindigkeit von Leistungsbeurteilungen getrennt werden.
📉 Wie man die Geschwindigkeit korrekt berechnet
Eine genaue Berechnung erfordert Disziplin. Es reicht nicht aus, einfach die Punkte zusammenzuzählen. Der Prozess muss konsistent und transparent sein. Hier ist die Standardmethode zur Berechnung der Geschwindigkeit ohne Verzerrung.
1. Klären Sie, was „Fertig“ bedeutet
Eine Story wird nur dann in der Geschwindigkeit berücksichtigt, wenn sie die Definition von Fertig (DoD) erfüllt. Wenn eine Story zu 90 % abgeschlossen ist, zählt sie als null. Dadurch wird verhindert, dass Teams aufgrund von Teilarbeit überhöhte Zahlen melden. Die DoD sollte Code-Reviews, Tests und Dokumentation umfassen.
2. Abgeschlossene Arbeit aus früheren Sprints ausschließen
Arbeit, die aus einem vorherigen Sprint übernommen wurde, zählt nicht zur Geschwindigkeit des aktuellen Sprints. Nur Arbeit, die innerhalb des aktuellen Zeitrahmens abgeschlossen wurde, trägt zur Bewertung bei. Dadurch wird sichergestellt, dass der Maßstab die aktuelle Kapazität widerspiegelt.
3. Unterbrochene Sprints behandeln
Was passiert, wenn ein Sprint unterbrochen wird? Wenn ein Sprint aufgrund unvorhergesehener Umstände abgebrochen wird, ist die Geschwindigkeit für diesen Zeitraum ungültig. Zählen Sie sie nicht in den Durchschnitt ein. Notieren Sie stattdessen die Unterbrechung und verwenden Sie den nächsten vollständigen Sprint für die Berechnung.
4. Konsistenz bei Story Points
Das Team muss sich darauf einigen, was ein „Punkt“ bedeutet. Er sollte relativ, nicht absolut in Zeit gemessen sein. Wenn das Team beschließt, dass ein Punkt einer bestimmten Komplexität entspricht, muss diese Standards über die Zeit konstant bleiben. Eine Änderung der Skala in der Mitte eines Projekts macht die historischen Geschwindigkeitsdaten ungültig.
📈 Geschwindigkeit zur Prognose nutzen, nicht zur Belastung
Der primäre Einsatz der Geschwindigkeit liegt in der Prognose. Sie hilft dem Team zu beantworten: „Wie viele Sprints werden benötigt, um dieses Backlog abzuschließen?“ Sie beantwortet nicht: „Arbeitet ihr hart genug?“
Die Prognose basiert auf dem Begriff des Durchschnitts. Die Geschwindigkeit eines einzelnen Sprints ist störanfällig. Sie schwankt aufgrund von Feiertagen, Krankheitstagen oder technischen Herausforderungen. Um eine zuverlässige Prognose zu erhalten, verwende die durchschnittliche Geschwindigkeit der letzten 3 bis 5 Sprints.
Diese Glättungswirkung reduziert die Auswirkungen von Anomalien. Sie bietet eine realistische Sicht auf die Kapazität. Wenn Stakeholder ein Lieferdatum verlangen, kann das Team sagen: „Basierend auf unserer durchschnittlichen Geschwindigkeit von 35 Punkten pro Sprint und einem verbleibenden Backlog von 140 Punkten schätzen wir 4 Sprints.“
Dieser Ansatz ist datengestützt, aber nicht strafend. Er beruht auf den eigenen historischen Daten des Teams, nicht auf externen Erwartungen.
🔄 Alternativen und ergänzende Metriken
Die Geschwindigkeit ist nicht die einzige Metrik, die zählt. Tatsächlich kann die alleinige Abhängigkeit von der Geschwindigkeit wichtige Probleme verbergen. Eine hohe Geschwindigkeit garantiert kein gesundes Team oder ein stabiles Produkt. Überlege, ein Dashboard mit Metriken zu verwenden, um ein vollständiges Bild zu erhalten.
| Metrik | Was es misst | Warum es wichtig ist |
|---|---|---|
| Geschwindigkeit | Ausgabe pro Sprint | Prognose der zukünftigen Kapazität |
| Zykluszeit | Zeit von der Start- bis zur Endphase | Identifizierung von Engpässen im Fluss |
| Lead Time | Zeit von der Anfrage bis zur Lieferung | Kundenreaktionsfähigkeit |
| Durchgefallene Fehler | Fehler, die in der Produktion gefunden wurden | Qualität und Stabilität |
| Erfolg des Sprint-Ziels | Erreichung der Ziele | Fokus und Wertlieferung |
Die Zykluszeit ist besonders nützlich, um Überlastung zu verhindern. Wenn die Zykluszeit steigt, ist das Team blockiert. Dies signalisiert, dass sie Hilfe bei Hindernissen benötigen, bevor weitere Arbeit in die Warteschlange aufgenommen wird. Die Geschwindigkeit könnte hoch bleiben, während die Zykluszeit stark ansteigt, was ein falsches Gefühl von Gesundheit erzeugt.
🧘 Psychologische Sicherheit und Teamgesundheit
Der wichtigste Faktor für eine nachhaltige Geschwindigkeit ist psychologische Sicherheit. Die Teammitglieder müssen sich sicher fühlen, wenn sie zugeben, dass sie Schwierigkeiten haben, ohne Angst vor Strafe. Wenn ein Entwickler ein Problem verheimlicht, um die Geschwindigkeitszahl zu schützen, wird die Metrik nutzlos.
Führungskräfte und Scrum Masters spielen hier eine entscheidende Rolle. Sie müssen betonen, dass die Geschwindigkeit ein Werkzeug für das Team ist, kein Werkzeug für die Managementebene. In der Retrospektive sollten Geschwindigkeitstrends offen diskutiert werden. Stelle Fragen wie:
- Haben wir genau geschätzt?
- Sind wir auf unerwartete technische Schulden gestoßen?
- Hat die Definition des Erfolgs uns verlangsamt?
- Fühlen wir uns unter Druck, früh zu Ende zu bringen?
Wenn die Antwort auf die letzte Frage ja lautet, muss sich der Fokus auf die Kapazitätsplanung verlagern. Es ist besser, weniger Stories mit hoher Qualität abzuschließen, als sich zu beeilen und Dinge zu beschädigen.
🚫 Häufige Fallen, die vermieden werden sollten
Es gibt spezifische Fallen, in die Teams oft geraten, wenn sie die Geschwindigkeit verfolgen. Die frühzeitige Erkennung dieser Fallen kann ein Projekt vor dem Scheitern bewahren.
1. Vergleich von Teams
Der Vergleich der Geschwindigkeit von Team A mit der von Team B ist ein grundlegender Fehler. Jedes Team verfügt über unterschiedliche Fähigkeiten, unterschiedliche Kontexte und unterschiedliche Definitionen eines Storypoints. Team A könnte eine hohe Geschwindigkeit haben, weil ihre Punkte klein sind. Team B könnte eine niedrige Geschwindigkeit haben, weil sie schwierigere Probleme angehen. Der Vergleich erzeugt Groll und treibt Teams dazu, das System zu manipulieren.
2. Zahlenjagd
Wenn ein Team das Gefühl hat, eine bestimmte Zahl erreichen zu müssen, hört es auf, sich auf den Wert zu konzentrieren. Sie könnten große Stories in winzige aufteilen, um die Anzahl zu erhöhen. Dies erhöht die Verwaltungskosten und die Fragmentierung. Konzentrieren Sie sich auf den gelieferten Wert, nicht auf die angesammelten Punkte.
3. Ignorieren der Kapazität
Die Geschwindigkeit geht von einer Verfügbarkeit von 100 % aus. Sie berücksichtigt keine Urlaubszeiten, Besprechungen oder Support-Arbeit. Ein Team mit 5 Mitgliedern könnte theoretisch eine Kapazität von 50 Punkten haben. Wenn zwei Mitglieder im Urlaub sind, sinkt die tatsächliche Kapazität. Passen Sie immer die Kapazität bei der Sprintplanung an.
4. Verwendung der Geschwindigkeit für individuelle Bewertungen
Die Verbindung der Geschwindigkeit mit individuellen Boni oder Leistungsbeurteilungen ist ein direkter Weg zu Überlastung. Es fördert das Verstecken von Informationen und das Verweigern der Hilfe für andere. Die Arbeit sollte auf der kollektiven Leistung des Teams, nicht auf individuellen Beiträgen, bewertet werden.
🛠️ Einführung eines gesunden Prozesses
Der Übergang zu einem gesunden System zur Verfolgung der Geschwindigkeit dauert Zeit. Es erfordert eine Veränderung der Denkweise. Hier ist ein schrittweiser Ansatz, um dies verantwortungsvoll umzusetzen.
Schritt 1: Schulung der Stakeholder
Bevor die Verfolgung beginnt, erklären Sie den Stakeholdern, was Geschwindigkeit ist und was sie nicht ist. Sie müssen verstehen, dass es eine Prognose, keine Verpflichtung ist. Es ist ein Team-Maßstab, kein Management-Tool. Dadurch werden Erwartungen früh gesetzt.
Schritt 2: Festlegung einer Basis
Erwarten Sie keine Genauigkeit im ersten Sprint. Die ersten Sprints dienen der Abstimmung. Nutzen Sie die Daten, um das natürliche Tempo des Teams zu finden. Machen Sie keine Änderungen allein aufgrund der Zahlen des ersten Sprints.
Schritt 3: Überprüfung in Retrospektiven
Machen Sie die Geschwindigkeit zu einem regelmäßigen Thema in den Retrospektiven. Diskutieren Sie die Abweichung zwischen geplanten und tatsächlichen Werten. Wenn das Team 40 Punkte geplant und 30 abgeschlossen hat, analysieren Sie, warum. War die Schätzung falsch? Gab es Unterbrechungen? Dies schafft eine Feedbackschleife zur Verbesserung.
Schritt 4: Anpassung der Planung
Verwenden Sie die durchschnittliche Geschwindigkeit zur Planung zukünftiger Sprints. Wenn der Durchschnitt 30 beträgt, planen Sie nicht für 40. Planen Sie für 30. Wenn das Team konsequent mehr abschließt, wird es seine Kapazität in zukünftigen Planungssitzungen natürlich erhöhen. Lassen Sie das Team die Erhöhung vorantreiben, nicht die Managementebene.
Schritt 5: Überwachung des Wohlbefindens
Achten Sie auf die Stimmung des Teams. Wenn die Geschwindigkeit hoch ist, aber die Stimmung niedrig, stimmt etwas nicht. Hohe Geschwindigkeit kann ein Symptom für Überarbeitung sein. Priorisieren Sie das Wohlbefinden gegenüber der Geschwindigkeit. Ein ausgeruhtes Team liefert im Langzeitverlauf besseren Code schneller.
📉 Umgang mit Schwankungen der Geschwindigkeit
Die Geschwindigkeit wird schwanken. Das ist normal. Ein Team könnte einen hohen Sprint haben, gefolgt von einem niedrigen Sprint. Das ist kein Versagen; das ist die Realität. Faktoren, die die Schwankungen beeinflussen, sind:
- Teamzusammensetzung: Neue Mitglieder im Onboarding verringern die Geschwindigkeit vorübergehend.
- Technische Schuld: Die Reduzierung von Schulden verlangsamt oft die Geschwindigkeit neuer Features.
- Externe Abhängigkeiten: Warten auf Dritte stoppt den Fortschritt.
- Sprint-Länge: Die Änderung der Sprint-Länge beeinflusst die insgesamt verfügbaren Punkte.
Wenn eine Varianz auftritt, panikartig reagieren Sie nicht. Schauen Sie sich die Entwicklung im Laufe der Zeit an. Ein einzelner Datenpunkt ist Rauschen; eine Trendlinie ist eine Signalfunktion. Wenn der Trend über drei aufeinanderfolgende Sprints hinweg abwärts geht, untersuchen Sie die Ursache. Wird die Arbeit schwieriger? Ist das Team überfordert?
💡 Die Rolle des Scrum Masters
Der Scrum Master ist der Wächter des Prozesses. Er muss das Team vor externem Druck schützen, der die Geschwindigkeit manipulieren soll. Wenn ein Product Owner im nächsten Sprint mehr Punkte verlangt, sollte der Scrum Master ihn dazu anleiten, die durchschnittliche Geschwindigkeit und Kapazität zu betrachten.
Der Scrum Master stellt auch sicher, dass das Team die Metriken nicht manipuliert. Er fördert ehrliche Schätzungssitzungen. Er ermutigt das Team, während der Sprint-Planung „Nein“ zu sagen, wenn die Arbeitslast zu hoch ist. Dieser Schutz ist für die langfristige Nachhaltigkeit entscheidend.
🌱 Aufbau einer nachhaltigen Arbeitsgeschwindigkeit
Agile geht es um Nachhaltigkeit. Der Scrum Guide betont eine nachhaltige Arbeitsgeschwindigkeit. Das bedeutet, dass das Team seine Geschwindigkeit unbegrenzt ohne Erschöpfung beibehalten kann. Wenn ein Team ausbrennt, um ein Ziel zu erreichen, ist das Ziel falsch.
Eine nachhaltige Arbeitsgeschwindigkeit ermöglicht kontinuierliche Verbesserung. Sie ermöglicht Lernen. Sie ermöglicht ein Leben außerhalb der Arbeit. Wenn die Verfolgung der Geschwindigkeit dies unterstützt, wird sie zu einem mächtigen Werkzeug. Wenn sie dies untergräbt, wird sie zu einer Belastung.
Konzentrieren Sie sich auf die Qualität der Arbeit. Konzentrieren Sie sich auf das Wohlbefinden des Teams. Konzentrieren Sie sich auf den Wert, den Sie dem Kunden liefern. Die Geschwindigkeit wird sich von selbst ergeben, wenn diese drei Säulen stark sind.
🔍 Letzte Überlegungen zur Messung
Die Verfolgung der Scrum-Geschwindigkeit ist ein notwendiger Bestandteil der agilen Planung, erfordert aber Vorsicht. Es ist eine Metrik der Kapazität, keine Messung des Wertes. Indem man sie als ein privates Werkzeug für das Entwicklungsteam behandelt, können Organisationen die Fallen der Mikroverwaltung vermeiden.
Denken Sie daran, dass Daten nur dann nützlich sind, wenn sie zu besseren Entscheidungen führen. Wenn Geschwindigkeitsdaten zu Stress führen, wird sie falsch verwendet. Richten Sie den Fokus erneut auf Vorhersagbarkeit und Fluss. Verwenden Sie ergänzende Metriken wie die Zykluszeit, um ein vollständigeres Bild der Gesundheit zu erhalten.
Letztendlich geht es nicht darum, eine Zahl zu maximieren. Ziel ist es, Wert konsistent und nachhaltig zu liefern. Wenn das Team sich sicher und unterstützt fühlt, wird die Geschwindigkeit zu einer natürlichen Abbildung ihrer Fähigkeiten, nicht zu einem Ziel, das verfolgt werden muss. 🎯
Übernehmen Sie diese Praktiken, um ein Team aufzubauen, das nicht nur produktiv, sondern auch widerstandsfähig ist. Ein widerstandsfähiges Team ist das wertvollste Gut, das eine Organisation haben kann.
