Scrum ist als agiles Framework mittlerweile aus der Softwareentwicklung und anderen Domänen kaum noch wegzudenken. Eines der zentralen Werkzeuge, um die Produktivität und den Erfolg deines Scrum-Teams zu messen und zu optimieren, ist die sogenannte Velocity. Doch leider wird dieser Wert oft missverstanden oder falsch angewendet, was zu Frustration im Team oder unrealistischen Erwartungen führt. In diesem Artikel zeige ich dir, wie du die Velocity sinnvoll nutzt, einige weniger bekannte Strategien, die deinem Team helfen können, damit besser zu arbeiten, und praktische Beispiele, um die Konzepte zu verdeutlichen.
Was ist Velocity?
Die Velocity im Scrum ist ein Maß dafür, wie viel Arbeit dein Team innerhalb eines Sprints erledigen kann. Es handelt sich dabei um eine Zahl, die (oft) die Summe der Story Points darstellt, die das Team in einem Sprint fertiggestellt hat. Die wichtige Grundlage hierbei ist, dass Story Points keine realen Zeiteinheiten wie Stunden oder Tage darstellen, sondern die relative Komplexität oder den Aufwand einer Aufgabe.
Warum ist das so wertvoll? Ganz einfach: Sie hilft euch als Team, realistisch zu planen, kontinuierlich besser zu werden und Fortschritte sichtbar zu machen. Wenn du beispielsweise weißt, dass dein Team durchschnittlich 40 Story Points pro Sprint schafft, kannst du besser abschätzen, wie lange es dauern wird, bis ein Produkt-Release oder eine größere Funktion fertiggestellt ist. Damit das funktioniert, muss die Geschwindigkeit jedoch korrekt gemessen und eingesetzt werden.
Vorteile
Relative Schätzung statt genauer Zeiterfassung
Story Points zur Geschwindigkeitsbestimmung messen den relativen Aufwand oder die Komplexität einer Aufgabe, anstatt sich auf Zeitangaben wie Stunden zu fokussieren. Das ist effektiver, da Schätzungen in Stunden oft ungenau sind und durch persönliche Arbeitsgeschwindigkeiten oder externe Störungen beeinflusst werden. Beispiel: Was für einen erfahrenen Entwickler 4 Stunden dauert, könnte für einen neuen Kollegen 8 Stunden bedeuten – die Story Point-Bewertung von „5“ bleibt jedoch gleich.
Besserer Fokus auf den Mehrwert
Während Stundenplanungen häufig den Arbeitsaufwand betonen, fördert die Velocity die Diskussion über die tatsächliche Aufgabe und den Kundennutzen. Story Points helfen deinem Team, die Bedeutung und Priorität einer Aufgabe im Kontext zu verstehen, anstatt nur die benötigte Zeit abzuwägen. Beispiel: Eine wichtige Funktion mit großer Komplexität wird eher sinnvoll priorisiert und besprochen, da Story Points darauf hinweisen, dass sie größere Aufmerksamkeit erfordert.
Geringere Schätzlast für Einzelpersonen
Bei der Arbeit mit Stunden müssen Teammitglieder oft detaillierte Zeitangaben machen, was besonders bei komplexen Aufgaben schwierig ist. Velocity erlaubt dem Team, als Ganzes zu schätzen: „Wie komplex ist diese Aufgabe relativ zu anderen?“ Dies reduziert den Druck, exakte Vorhersagen zu machen, und führt zu schnelleren und konsistenteren Planungen.
Berücksichtigung von Teamdynamik und Geschwindigkeit
Velocity ist eine Teammessung – sie reflektiert die gesamte Arbeitsleistung innerhalb eines Sprints. Im Gegensatz dazu ignoriert eine Stundenplanung oft Variablen wie Urlaub, unvorhergesehene Unterbrechungen oder unterschiedliche Fähigkeiten im Team. Beispiel: Wenn das Team 30 Punkte pro Sprint erreicht, aber aufgrund eines Urlaubs nur zu 80 % besetzt ist, kann entsprechend geplant werden, ohne Stunden neu berechnen zu müssen.
Förderung einer realistischeren Planung
Die Velocity basiert auf historischen Daten und macht es einfacher, realistische Sprint-Ziele zu setzen. Anstatt Stunden zu überschätzen (oder zu unterschätzen), stützt sich dein Team auf die nachgewiesene Leistung vergangener Sprints. Beispiel: Wenn das Team in den letzten fünf Sprints zwischen 20 und 25 Story Points abgeschlossen hat, könnt ihr euren nächsten Sprint besser auf 22 Punkte auslegen, statt auf 30 Stunden zu schätzen.
Steigerung der Teamtransparenz und Verbesserung
Eine emprirische Geschwindigkeit macht es leichter, Verbesserungsmöglichkeiten im Team zu erkennen. Wenn sie über mehrere Sprints hinweg schwankt, könnt ihr in der Retrospektive die Ursachen analysieren – sei es durch Blocker oder ineffiziente Prozesse. Stundenberichte bieten hingegen oft nur Details einzelner Aufgaben, sind jedoch weniger hilfreich bei der Analyse des Gesamtbilds.
Flexibilität durch unabhängige Schätzmethoden
Story Points sind unabhängig von den individuellen Arbeitsgewohnheiten und Tagesformen. Dies macht sie besonders effektiv für Teams mit unterschiedlichen Erfahrungsstufen oder crossfunktionalen Rollen. Beispiel: Ein Designer, ein Entwickler und ein Tester können gemeinsam Story Points schätzen, da der Fokus auf dem relativen Aufwand der Gesamtaufgabe liegt – und nicht darauf, wie viele Stunden jeder Einzelne benötigt.
Förderung von Teamarbeit und gemeinsamen Zielen
Wenn Teams mit Velocity arbeiten, liegt der Fokus auf dem Abschluss von User Stories als Team, anstatt individuelle Arbeitsstunden im Blick zu haben. Dies fördert die Zusammenarbeit, da das Ziel darin besteht, die Sprintziele gemeinsam zu erreichen. Beispiel: Kommt es bei einer Aufgabe zu Verzögerungen, springt ein anderes Teammitglied ein, um sicherzustellen, dass die Story fertig wird – die Gesamt-Velocity im Sprint bleibt dadurch stabil.
Mythos: Höhere Velocity bedeutet besseres Team
Ein häufiger Fehler ist die Annahme, dass eine ständig steigende Velocity ein Zeichen für ein gutes Team ist. Das ist jedoch ein Trugschluss. Es kann viele Gründe haben, und nicht alle sind positiv. Es könnte z. B. sein, dass dein Team plötzlich mehr Kapazität hat, weil weniger Support-Aufgaben anfallen – oder aber es werden bewusst kleinere Aufgaben erstellt, um die Velocity künstlich in die Höhe zu treiben (ja, auch das passiert in der Praxis). Statt dich nur auf eine steigende Zahl zu konzentrieren, solltest du dich fragen: „Erledigen wir wirklich die richtigen Aufgaben, die den Kundenwert maximieren?“
Nur länger betrachtete empirische Daten sind wertvoll
Lasse dich nicht von wenigen Sprints auf die falsche Fährte locken: Du brauchst mindestens 3-5 Sprints, damit eine erste Velocity eine Aussagekraft haben kann.
Weniger bekannte Strategien, um die Velocity zu optimieren
Hier stelle ich dir einige umsetzbare Strategien vor, die über die klassischen Tipps hinausgehen. Sie helfen dir, die Velocity sinnvoll zu nutzen und gleichzeitig die Leistung deines Teams zu verbessern.
Kontinuität in der Schätzung sicherstellen
Oft kommt es vor, dass unterschiedliche Teammitglieder Story Points unterschiedlich bewerten – besonders, wenn das Team neu ist oder sich verändert. Eine geringfügig abweichende Einschätzung mag im Einzelfall nicht schlimm erscheinen, kann jedoch die langfristige Konsistenz deiner Velocity stark beeinträchtigen. Eine einfache Lösung: Halte regelmäßig „Refinement-Workshops“ ab, bei denen ihr konkrete Beispiele aus der Vergangenheit durchgeht und als Team diskutiert, warum eine bestimmte Aufgabe mit 5 Punkten bewertet wurde und eine andere mit 8. So schärft ihr eure gemeinsame Einschätzung.
Störungen und Kapazitätstracker im Blick behalten
Velocity wird oft als absolutes Maß betrachtet, ohne die äußeren Einflüsse einzubeziehen. Dabei gibt es immer wieder Störungen: Urlaube, unerwartete Meetings, wichtige Ad-hoc-Anfragen von Kunden oder technische Probleme. Um die Velocity ehrlich und realistisch zu messen, empfiehlt es sich, einen Kapazitätstracker einzuführen. Dort hältst du fest, wie viele verfügbare Arbeitstage das Team tatsächlich im Sprint hatte. So kannst du feststellen, ob die Velocity abnimmt, weil das Team überlastet war, oder ob andere Ursachen dahinterstecken.
Experimentiere mit der Teamzusammensetzung
Oft wird der Zusammenhang zwischen Teamdynamik und Velocity unterschätzt. Ein Beispiel aus meiner Praxis: Ein Scrum-Team hatte über Monate hinweg eine stagnierende Velocity von etwa 25 Punkten pro Sprint. Nach Gesprächen stellte sich heraus, dass gewisse Teammitglieder stark auf Bereiche spezialisiert waren, was zu Flaschenhälsen führte. Durch gezielte Pair-Programming-Sessions und die Verlagerung von Wissen konnten wir die Zusammenarbeit verbessern, und die Velocity stieg auf 30 Punkte pro Sprint – ohne zusätzlichen Druck auf das Team.
Breite Pufferzonen einplanen
Während der Sprint-Planung solltest du mit deinem Team immer einen gewissen Puffer einplanen, insbesondere wenn die Velocity stark schwankt. Ein Beispiel: Wenn deine letzte Sprint-Velocity bei 35 Punkten lag, solltest du für den nächsten Sprint nur Arbeit für etwa 80–90 % (also etwa 28 bis 32 Punkte) einplanen. Dies gibt Raum für unerwartete Herausforderungen und ermöglicht es deinem Team, nachhaltig zu arbeiten, anstatt ständig in den nächsten Burnout zu steuern.
Experiment: Bewusst die Velocity-Grenzen ausloten
Anstatt Puffer einzuplanen, könnt ihr auch einmal bewusst experimentieren, indem ihr mehr Story Points in den Sprint nehmt, als eure durchschnittliche Velocity vermuten lässt. Wichtig ist hierbei, dass ihr dieses Vorgehen als zeitlich begrenztes Experiment mit klaren Hypothesen und messbaren KPIs definiert. Eine mögliche Hypothese könnte lauten: "Wenn wir 120% unserer durchschnittlichen Velocity (z.B. 42 Punkte statt 35) einplanen, steigert dies den Fokus und die Zusammenarbeit im Team und führt letztendlich zu einer höheren tatsächlichen Velocity, ohne die Qualität zu beeinträchtigen." Um diese Hypothese zu überprüfen, müsst ihr KPIs definieren. Neben der erreichten Velocity könnten das z.B. die Anzahl der fertiggestellten Story Points, die Anzahl der Bugs, die im nächsten Sprint behoben werden müssen (als Indikator für Qualitätsverluste) und der Team-Happiness-Score (z.B. mittels einer kurzen Umfrage am Ende des Sprints) sein. Dokumentiert eure Ergebnisse sorgfältig und wertet sie nach dem Experiment gemeinsam aus. Bestätigt sich die Hypothese, könnt ihr die Strategie weiterverfolgen. Stellt ihr jedoch negative Auswirkungen fest, wie z.B. eine hohe Anzahl an unfertigen Story Points oder sinkende Teamzufriedenheit, solltet ihr zum vorherigen Vorgehen zurückkehren. Dieses Experiment erfordert Mut und Transparenz, kann aber wertvolle Erkenntnisse über die tatsächliche Leistungsfähigkeit und die versteckten Reserven eures Teams liefern. Denkt daran, dieses Experiment nur für einen oder zwei Sprints durchzuführen und die Ergebnisse im Team offen zu diskutieren.
Die Velocity als Gesprächsgrundlage nutzen – nicht als Ziel
Um dein Team nicht unter Druck zu setzen, solltest du klarstellen, dass die Velocity keine Zielvorgabe ist, sondern ein Startpunkt für Diskussionen. Falls es eine Diskrepanz zwischen der geplanten und tatsächlichen Velocity gibt, kann das an vielen Faktoren liegen: Fehler in der Planung, unvorhergesehene Blocker oder auch Unzufriedenheit im Team. Nutze die Retrospektive nach dem Sprint, um die Gründe zu analysieren, statt Schuldzuweisungen zu machen oder die Leute durch unrealistische Erwartungen zu frustrieren.
Fazit
Die Velocity in Scrum ist ein extrem wirkungsvolles Werkzeug, wenn sie richtig genutzt wird. Sie hilft dir, realistischer zu planen, Fortschritte zu verfolgen und Probleme im Arbeitsprozess sichtbar zu machen. Wichtig ist jedoch, die Velocity nicht als absolutes Ziel oder Leistungsmaßstab zu verwenden, sondern als Gesprächsgrundlage für Verbesserung. Probiere einige der Strategien, die ich dir vorgestellt habe, mit deinem Team aus, und beobachte, wie sich die Zusammenarbeit und das Gesamtergebnis über die Zeit verbessern. Scrum ist ein gemeinsamer Lernprozess – und je besser ihr zusammenarbeitet, desto erfolgreicher werden eure Projekte!