Velocity und Kapazität sind die beiden Kennzahlen, die einen Sprint realistisch halten, und Teams, die diese beiden Begriffe verwechseln, übernehmen sich Sprint für Sprint. Velocity gibt an, wie viel Arbeit Sie in der Vergangenheit pro Sprint erledigt haben. Kapazität gibt an, wie viel Zeit Ihnen in diesem Sprint tatsächlich zur Verfügung steht. Sie beantworten unterschiedliche Fragen, und wenn sie voneinander abweichen, ist in der Regel der kleinere Wert der richtige.

Die Unterscheidung, die oft übersehen wird

Die Velocity ist rückblickend: Wenn Sie den Durchschnitt der Story-Punkte bilden, die Ihr Team in den letzten Sprints abgeschlossen hat, erhalten Sie eine realistische Erwartungshaltung für einen normalen Sprint. Dadurch werden die Schwankungen einzelner Sprints geglättet und zu einer Planungsgrundlage zusammengefasst. Da diese Punkte aus der Schätzung stammen, führt eine straffere Vorgehensweise bei der gemeinsamen Schätzung als Team – sollten Ihre Zahlen schwanken – zu einer Stabilisierung des Velocity-Durchschnitts, auf den sich die Planung stützt.

Die Kapazität ist zukunftsorientiert und bezieht sich speziell auf den vor Ihnen liegenden Sprint. Zwei Entwickler im Urlaub, ein Feiertag, eine Woche mit hohem Bereitschaftsdienst, die Vollbesetzung am Donnerstag: Nichts davon schlägt sich in Ihrem Durchschnittswert für die Velocity nieder, doch all dies beeinträchtigt den Sprint, den Sie gerade planen.

Die Velocity gibt Ihnen also Aufschluss darüber, wie ein typischer Sprint aussieht. Die Kapazität zeigt Ihnen, ob dieser Sprint typisch ist. Wenn Sie sich ausschließlich auf die Velocity stützen, gerät jeder Sprint, der durch Feiertage verkürzt oder durch Urlaubstage stark beeinträchtigt ist, aus den Fugen. Planen Sie ausschließlich anhand der Kapazität, und Sie verlieren den Maßstab, der Sie davor bewahrt, einen normalen Sprint massiv zu über- oder zu unterlasten. Sie benötigen beides, und wenn sie im Widerspruch zueinander stehen, vertrauen Sie der Kapazität. Sie weiß etwas, was der Durchschnittswert nicht weiß.

Capacity in hours versus velocity in points — different units Capacity ≈ 120 h hours available Velocity ≈ 30 pts points delivered different units — you can't convert one into the other
Die Geschwindigkeit entspricht dem historischen Durchschnitt; die Kapazität gibt an, was in diesem Sprint tatsächlich geleistet werden kann. Wenn ein Feiertag oder eine Woche mit hohem Supportaufkommen die Kapazität unter die Geschwindigkeit senkt, planen Sie anhand des niedrigeren Werts. Der Durchschnitt berücksichtigt den Feiertag nicht.

Kapazitätsberechnungen, auf die Sie sich verlassen können

Die Kapazitätsberechnung ist einfache Arithmetik, bei der Teams aufgrund ihres Optimismus regelmäßig Fehler machen. Beginnen Sie mit einem hohen Wert und ziehen Sie ehrlich ab:

  1. Arbeitstage im Sprint × Anzahl der Mitarbeiter. Ihr Bruttoausgangssumme.
  2. Geplante Abwesenheiten abziehen: Urlaub, Feiertage, Teilzeitregelungen.
  3. Feste Termine abziehen: die Zeremonien selbst, wiederkehrende Besprechungen, Einzelgespräche.
  4. Ziehen Sie den Support- und Unterbrechungsaufwand ab: Bereitschaftsdienst, Produktionsprobleme, „kurze Fragen“, die niemals kurz sind. Wenn Sie einen Support-Rotationsplan haben, steht die betreffende Person nicht für die Sprint-Arbeit zur Verfügung; zählen Sie sie daher nicht mit.
  5. Halten Sie sich einen Spielraum für Unvorhergesehenes offen. Es kommt immer etwas dazwischen. Ein Team, das seine verbleibende Zeit zu 100 % verplant, hat bereits beim ersten Eingriff der Realität sein Scheitern vorprogrammiert.

Was bleibt, ist die Kapazität. Der häufigste Fehler besteht darin, die Schritte 4 und 5 zu überspringen. Die „Interrupt-Belastung“ ist real, und ein Sprint, der so geplant wird, als würde sie nicht auftreten, ist ein Sprint, der für ein Team geplant ist, das es gar nicht gibt.

Velocity ist ein Planungsinstrument, kein Ergebnisdisplay

An diesem Punkt wird die Velocity zunichte gemacht. Die Velocity dient genau einem einzigen Zweck: einem einzelnen Team dabei zu helfen, seine eigenen zukünftigen Sprints zu planen. In dem Moment, in dem sie zu einem Wachstumsziel oder zu einem Maßstab für den Vergleich zwischen Teams wird, verliert sie jegliche Aussagekraft, denn der einfachste Weg, die Velocity zu steigern, besteht darin, die Schätzungen zu überhöhen – und genau das tun alle stillschweigend.

Story-Punkte beziehen sich auf das gemeinsame Verständnis eines Teams hinsichtlich des Umfangs. Sie sind nicht übertragbar. Die 8 von Team A entspricht nicht der 8 von Team B; daher ist die Aussage „Team A hat 60 Punkte erreicht und Team B 40“ ein Vergleich zweier unterschiedlicher Maßstäbe. Die Velocity dient als Planungshilfe, nicht als Punktestand. Respektieren Sie diese Grenze, dann bleibt sie nützlich.

Wie die Velocity konkret berechnet wird, über wie viele Sprints der Durchschnitt ermittelt wird und wie mit einem brandneuen Team ohne bisherige Daten umgegangen wird, erfahren Sie im Kapitel zur Velocity im Schätzungsleitfaden. Dort werden die Mechanismen ausführlich behandelt, sodass sich dieses Kapitel ganz auf die Planung konzentrieren kann. Und sollten die Schätzungen, aus denen sich Ihre Velocity ergibt, unzuverlässig sein, handelt es sich dabei um ein Schätzungsproblem, das im Refinement und nicht in der Planung behoben werden muss.

Beides bei der Planung einbeziehen

In diesem Zusammenhang spielen die beiden Zahlen unterschiedliche Rollen. Die Kapazität legt die Obergrenze fest: Nehmen Sie so lange Aufgaben auf, bis die geschätzte Gesamtmenge Ihre berechnete Kapazität für den Sprint erreicht, und hören Sie dann auf. Die Velocity dient als Plausibilitätsprüfung: Wenn Ihre auf der Kapazität basierende Auswahl deutlich über oder unter Ihrer normalen Velocity liegt, stimmt etwas nicht (entweder Ihre Kapazitätsberechnung oder Ihre Schätzungen), und es lohnt sich, dies noch einmal zu überprüfen, bevor Sie eine Entscheidung treffen.

In der Praxis: Ermitteln Sie zunächst die Kapazität, nutzen Sie diese als feste Obergrenze bei selection und werfen Sie einen Blick auf die Velocity, um sicherzustellen, dass das Ergebnis nicht überraschend ausfällt. Wenn Kapazität und Velocity nicht übereinstimmen, weil der Sprint unterbesetzt ist oder durch Urlaub verkürzt wurde, nehmen Sie den kleineren Wert und fahren Sie fort. Eine zu niedrige Zielsetzung kostet Sie ein wenig Slack; eine zu hohe Zielsetzung kostet Sie das Sprintziel.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Durchsatz und Kapazität?

Die Velocity gibt an, wie viel Arbeit ein Team in der Vergangenheit pro Sprint erledigt hat, gemessen in Story-Punkten: ein rückblickender Durchschnitt. Die Kapazität gibt an, wie viel Zeit dem Team in diesem Sprint tatsächlich zur Verfügung steht, nach Abzug von Urlaub, Besprechungen und Supportaufwand. Die Velocity gibt Aufschluss über einen normalen Sprint; die Kapazität gibt Aufschluss darüber, ob dieser Sprint normal ist. Sie benötigen beides.

Wie berechnen Sie die Teamkapazität für einen Sprint?

Gehen Sie von den Arbeitstagen im Sprint aus, multiplizieren Sie diese mit der Anzahl der Teammitglieder und ziehen Sie dann die tatsächlichen Abzüge ab: geplanten Urlaub, gesetzliche Feiertage, regelmäßige Besprechungen und Feierlichkeiten, Support- oder Bereitschaftsdienste sowie einen Puffer für Unvorhergesehenes. Was übrig bleibt, ist die Kapazität. Die meisten Teams überschätzen diese, da sie die „Unterbrechungssteuer“ außer Acht lassen.

Sollten Sie mit voller Geschwindigkeit vorgehen?

Nein. Die Velocity ist ein Durchschnittswert; sich daran zu orientieren bedeutet daher per Definition, in der Hälfte der Fälle zu viel zu planen. Planen Sie entsprechend Ihrer Kapazität für diesen konkreten Sprint und überprüfen Sie diese anhand der Velocity auf Plausibilität. Wenn die beiden Werte voneinander abweichen (beispielsweise bei einem durch Feiertage verkürzten Sprint), vertrauen Sie auf Ihre Kapazität und entscheiden Sie sich für den niedrigeren Wert.

Ist Geschwindigkeit ein Maß für Produktivität?

Nein, und wenn man sie als solche behandelt, macht man sie zunichte. Velocity dient als Planungshilfe für die eigene Prognose eines Teams. Sobald sie zu einem Ziel oder einem teamübergreifenden Vergleichsmaßstab wird, übertreiben die Teams ihre Schätzungen, und die Zahl ist als Messgröße nicht mehr aussagekräftig. Punkte lassen sich nicht zwischen Teams übertragen.