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 berechnen, die Ihr Team in den letzten Sprints abgeschlossen hat, erhalten Sie eine realistische Erwartung für einen normalen Sprint. Dadurch werden die Schwankungen einzelner Sprints geglättet und zu einer Planungsgrundlage zusammengefasst.

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 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 durch Feiertage verkürzte oder durch Urlaubstage stark beeinträchtigte Sprint aus den Fugen. Planen Sie ausschließlich anhand der Kapazität, und Sie verlieren die Kalibrierung, die 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 „Velocity“ entspricht dem historischen Durchschnitt; die Kapazität gibt an, was in diesem Sprint tatsächlich bewältigt werden kann. Wenn ein Feiertag oder eine Woche mit hohem Supportaufkommen die Kapazität unter die „Velocity“ senkt, sollten Sie Ihre Planung an dem niedrigeren Wert ausrichten – 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 Brutto-Ausgangszahl.
  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 für die Arbeit am Sprint nicht 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 das Scheitern vorprogrammiert.

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

Velocity ist ein Planungsinstrument, kein Ergebnisanzeiger

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 ihren Messwert – 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 und nicht als Punktestand – wenn Sie diese Grenze respektieren, bleibt sie nützlich.

Wie die Velocity konkret berechnet wird, wie viele Sprints in die Durchschnittsberechnung einfließen und wie mit einem brandneuen Team ohne bisherige Daten umgegangen werden soll, erfahren Sie im Kapitel zur Velocity im Schätzleitfaden – dort werden die Mechanismen ausführlich behandelt, sodass sich dieses Kapitel ganz auf die Planung konzentrieren kann. Und sollten die Schätzungen, auf denen Ihre Velocity basiert, unzuverlässig sein, handelt es sich 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 sich festlegen.

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 unerwartet 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 vorsichtige Planung kostet Sie ein wenig Slack; eine zu optimistische Planung 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 Durchschnittswert. 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 berechnet man 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 per Definition, in der Hälfte der Fälle zu viel zu übernehmen. 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 nicht übereinstimmen – beispielsweise bei einem durch Feiertage verkürzten Sprint –, vertrauen Sie auf Ihre Kapazität und nehmen Sie den niedrigeren Wert.

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

Nein, und wenn man es als solches behandelt, wird es zunichte gemacht. „Velocity“ ist eine Planungshilfe für die eigene Prognose eines Teams. Sobald es zu einem Ziel oder einem teamübergreifenden Vergleich wird, übertreiben die Teams ihre Schätzungen, und die Zahl ist nicht mehr aussagekräftig. Punkte lassen sich nicht zwischen Teams übertragen.