Kapazitätsplanung ohne die Hölle der Spreadsheets

Die meisten Kapazitätspläne beginnen mit einer Kopfzahl. Sechs Engineers im Team. Sechs verfügbare Engineers für den Sprint. Also wird die Arbeit für sechs Engineers eingeplant.

Dann endet der Sprint, und 40 % der geplanten Aufgaben wurden nicht geliefert. Alle zucken mit den Schultern und sprechen von "unvorhergesehenen Blockaden" und "unterschätzter Komplexität". Und der nächste Sprint beginnt mit denselben sechs Engineers und demselben optimistischen Commitment.

Das eigentliche Problem ist weder die Schätzqualität noch die Team-Velocity im Allgemeinen. Es ist, dass die Kapazitätsplanung Köpfe statt Stunden gezählt hat. Und reale Stunden, die verfügbaren, unterbrechungsreichen, meetingvollen, sehen dem Headcount überhaupt nicht ähnlich.

Ein Team aus sechs Engineers, die jede Woche je 12 Stunden in Meetings, 2 Stunden in Standups, 3 Stunden in Reviews und 2 Stunden in unerwarteten Unterbrechungen verbringen, hat pro Person und Woche ungefähr 20 Stunden für tatsächliche Arbeit. Nicht 40. Nicht einmal 30. Zwanzig. Und auf 100 % dieser 20 Stunden zu planen ignoriert die Varianz, die echte Arbeit unberechenbar macht. Die State-of-Teams-Studie von Atlassian ergab, dass Wissensarbeiter durchschnittlich 31 Stunden pro Woche in unproduktiven Meetings verbringen, was für deep work weit weniger Kapazität lässt, als die meisten Sprintpläne voraussetzen.

Die Lösung ist kein ausgefeilteres Spreadsheet. Es ist eine ehrlichere Buchführung darüber, was tatsächlich verfügbar ist. Dieselbe Ehrlichkeit, die ein Meeting-Überprüfung zutage fördert: Wenn Sie die Meeting-Stunden wirklich zählen, ist die verbleibende Zeit für echte Arbeit immer niedriger als angenommen.

Die versteckten Stunden, die Kapazität auffressen

Bevor Sie Kapazität genau planen können, müssen Sie wissen, wohin die Stunden tatsächlich fließen. Die meisten Manager, die diese Übung noch nicht gemacht haben, sind von den Ergebnissen überrascht.

Hier sind die Kategorien, die die meisten Kapazitätspläne ignorieren:

Wiederkehrende Meetings. Zählen Sie jedes Meeting im Kalender jedes Teammitglieds, das keine Projektarbeit ist. Standups, Team-Syncs, All-Hands, 1:1s, Skip-Levels, Meetings mit Partnerteams, Planungsmeetings, Review-Meetings. Für die meisten Wissensarbeiter sind das 8-15 Stunden pro Woche, ohne Ad-hoc-Meetings, die während des Sprints angesetzt werden.

On-Call und Interrupt-Rotationen. Teams mit On-Call-Verantwortung stellen oft fest, dass selbst "off-call"-Sprints eine Hintergrund-Interrupt-Last tragen. Jemand prüft immer die Queue. Jemand wird immer in ein Incident-Post-Mortem hineingezogen.

Review- und Feedback-Zyklen. Code-Reviews, Design-Reviews, Dokument-Feedback. Diese Arbeit ist real und kostet echte Zeit, wird aber meist als "Overhead" verbucht statt explizit erfasst. Für Senior Engineers und Leads kann die Review-Last 4-6 Stunden pro Woche betragen.

Administrativer Overhead. Ticket-Grooming, Projekt-Updates, Tool-Wartung, Compliance-Reviews. Niemand glorifiziert diese Arbeit, deshalb wird sie unterschätzt.

Manager-Zeit. Wenn Sie ein spielender Manager sind und die Sprint-Kapazität so planen, als hätten Sie 40 verfügbare Stunden, über-committen Sie systematisch. Ihre 1:1s, Ihre Team-Management-Aufgaben, Ihre bereichsübergreifende Koordination: Das ist alles keine Projektarbeit. Es gehört in die Overhead-Berechnung.

Teilzeit- und Split-Role-Teammitglieder. Wenn jemand 50 % seiner Zeit in einem anderen Team oder einer anderen Rolle verbringt, führt eine Planung zu 100 % Kapazität zu einem Sprint, der alle zwei Wochen um 50 % verfehlt wird.

Dieses Audit einmal für Ihr Team durchzuführen reicht normalerweise aus, um Ihre Planungsweise zu verändern. Die Zahlen sind fast immer ernüchternder als erwartet.

Die 20-%-Puffer-Regel

Selbst nach Berücksichtigung aller bekannten Overheads gibt es eine vorhersehbare Kategorie von Arbeit, die sich der Planung entzieht: das Unerwartete.

Das Unerwartete hat viele Formen. Ein kritischer Bug, der behoben werden muss, bevor sich sonst etwas bewegen kann. Eine Stakeholder-Frage, die sich in eine zweistündige Analyse verwandelt. Ein Teammitglied, das genau an dem Tag krank ist, an dem es das entscheidende Deliverable fertigstellen sollte. Eine Abhängigkeit, die sich anders auflöst als erwartet und Nacharbeit erfordert.

Sie können nicht vorhersagen, was in einem bestimmten Sprint passieren wird. Aber Sie können vorhersagen, dass etwas passieren wird. Über ein Jahr an Sprints hinweg absorbiert ungeplante Arbeit konsistent 15-25 % der Team-Kapazität.

Der 20-%-Puffer ist kein Pessimismus. Er ist empirisch. Wenn Sie ihn nicht explizit einbauen, passiert die ungeplante Arbeit trotzdem. Die McKinsey-Studie zu agilen Delivery-Teams ergab, dass leistungsstarke Teams konsistent auf 75-80 % der verfügbaren Kapazität planen und dass die Sprint-Abschlussraten bei Teams, die Puffer einsetzen, 35-40 % höher sind als bei Teams, die auf 100 % planen. Ohne Puffer ersetzt die ungeplante Arbeit einfach geplante Aufgaben. Dann sinken die Sprint-Completion-Raten, und alle reden über das Velocity-Problem des Teams, obwohl das eigentliche Problem war, dass die Kapazität auf 100 % ohne Spielraum für die Realität geplant wurde.

Praktisch bedeutet die Anwendung des 20-%-Puffers: Nach der Berechnung der real verfügbaren Stunden (nach Meetings, nach Overhead) reduzieren Sie das geplante Arbeitscommitment um 20 %. Hat das Team 120 verfügbare Stunden nach Overhead, planen Sie 96 Stunden committed work. Lassen Sie die anderen 24 als ungeplante Kapazität.

Das Drei-Spalten-Format

Sobald Sie ein klares Bild der echten Verfügbarkeit jeder Person haben, muss das Format der Kapazitätsplanung selbst nicht kompliziert sein. Eine Drei-Spalten-Ansicht reicht für die meisten Sprint-Planungen:

Verfügbare Stunden = Gesamte Arbeitsstunden im Sprint minus Meeting-Overhead minus Puffer (20 %)

Committed Work = Die konkreten Aufgaben, die diese Person in den Sprint nimmt, mit individuellen Stundenestimationen, die insgesamt die verfügbaren Stunden nicht übersteigen.

Der Spaltenvergleich macht Überzuteilung sofort sichtbar. Wenn die committed work einer Person 40 Stunden summiert und ihre Spalte "Verfügbare Stunden" 18 zeigt, haben Sie ein Gespräch zu führen, bevor der Sprint beginnt. Kein Rätsel, das nach dem Ende untersucht wird.

Kapazitätsprüfungen zum Sprintstart durchführen

Die häufigste Stelle, an der Kapazitätsplanung scheitert, ist das Timing. Teams führen eine Kapazitätsrevision bei der Quartalsplanung durch, committen sich auf eine Roadmap und beginnen dann jeden Sprint damit, Tickets zuzuweisen, ohne die Verfügbarkeit erneut zu prüfen.

Aber Verfügbarkeit ändert sich von Woche zu Woche. PTO wird eingetragen. Ein Partnerteam bittet um Zeit für eine Integration. Die On-Call-Rotation produziert eine Woche mehr Incidents als üblich. Ein Teammitglied geht in Urlaub.

Eine kurze Kapazitätsprüfung zu Beginn jedes Sprints, nicht quartalsweise, nicht monatlich, sondern zu Beginn jedes Sprints, verhindert die Drift zwischen dem Quartalsziel und dem, was das Team in den nächsten zwei Wochen tatsächlich leisten kann.

Die Kapazitätsprüfung zum Sprintstart dauert 15-20 Minuten:

1. Öffnen Sie das Drei-Spalten-Format. Tragen Sie die verfügbaren Stunden auf Basis bekannter Meetings und PTO vor.
2. Jedes Teammitglied überprüft seine Spalte und kennzeichnet alles, was die Verfügbarkeit in diesem Sprint beeinflussen wird (ein großes Code-Review, eine Zertifizierung, ein Arzttermin, der einen Vormittag kostet).
3. Passen Sie die verfügbaren Stunden entsprechend an.
4. Vergleichen Sie committed work mit verfügbaren Stunden. Bei einer Lücke verhandeln Sie neu, bevor der Sprint beginnt.

Das ist kein vollständiges Planungsmeeting. Es ist ein schneller Verfügbarkeits-Checkpoint. Konsequent durchgeführt verhindert es 80 % der Sprint-Misses, die der "Schätzung" zugeschrieben werden, aber eigentlich auf Verfügbarkeit zurückgehen.

Überzuteilung sichtbar kennzeichnen

Eines der wichtigsten Elemente eines gesunden Kapazitätsplanungsprozesses ist, dass Überzuteilung sichtbar und explizit ist, nicht verborgen und still absorbiert.

Wenn Sie in der Kapazitätstabelle sehen können, dass jemand 42 Stunden committed work gegen 20 Stunden Verfügbarkeit hat, haben Sie einen konkreten Diskussionspunkt. Entweder reduzieren Sie die committed work dieser Person (was Repriorisierung erfordert), oder Sie akzeptieren, dass einige Aufgaben nicht erledigt werden, und kommunizieren das jetzt an die Stakeholder statt am Ende des Sprints.

Das schlimmste Ergebnis ist das, bei dem die Überzuteilung nicht sichtbar ist. Das Teammitglied versucht, 42 Stunden Arbeit in einem 20-Stunden-Sprint zu erledigen. Es arbeitet abends und am Wochenende. Der Großteil der Arbeit ist erledigt, aber gehetzt. Einiges wird stillschweigend fallengelassen. Der Sprint endet mit einem unklaren Bild davon, was passiert ist und warum.

Sichtbare Überzuteilung schafft eine Verhandlung. Verborgene Überzuteilung schafft ein Scheitern.

Der Sprint-Verfügbarkeits-Tracker

Hier ist eine praktische Vorlage für die Erfassung der Sprint-Kapazität, die in ein gemeinsames Dokument oder Spreadsheet passt:

---

Sprint [Nummer], Kapazitätsübersicht Sprint-Zeitraum: [Start] bis [Ende]

---

Team-Verfügbarkeit

---

Committed Work

---

Überzuteilungs-Check [ ] Alle committed work passt in die verfügbaren Stunden
[ ] Bei Überzuteilung: Aufgaben gekennzeichnet und mit Stakeholdern neu verhandelt

---

Ungeplanter Puffer Gesamte verfügbare Stunden des Teams: [Summe]
Gesamte committed Stunden: [Summe]
Verbleibender Puffer: [Differenz, sollte ca. 20 % sein]

---

Das Überzuteilungs-Eskalationsskript

Wenn die Kapazitätsplanung Überzuteilung aufdeckt, brauchen Sie einen Weg, dies schnell und klar an Stakeholder zu kommunizieren. Hier ist ein einfaches Skript:

„Bei der Betrachtung der Sprint-Kapazität verfügt [Name] über [X Stunden] in diesem Sprint, hat aber [Y Stunden] committed work. Das ergibt eine Überzuteilung von [Z Stunden]. Wir müssen entweder [konkretes Element] in den nächsten Sprint verschieben oder mehr Kapazität bereitstellen. Wenn wir es so lassen, wird [konkretes Element] wahrscheinlich übertragen. Wie lautet die Prioritätsentscheidung?"

Diese Formulierung tut drei Dinge: Sie macht das Problem konkret (Zahlen, keine vagen Gefühle), sie präsentiert eine Wahl statt eines Problems, und sie bittet um eine Entscheidung statt um Mitgefühl. Stakeholder, die diese Formulierung erhalten, reagieren in der Regel konstruktiver als solche, die „wir werden einiges in diesem Sprint verpassen" hören.

Häufige Fehler

Planen auf 100 % Kapazität. Das ist die Ursünde der Kapazitätsplanung. Kein Mensch arbeitet für einen gesamten Sprint mit 100 % Effizienz. Es gibt immer Interrupts, Kontextwechsel und Varianz. 80 % ist ein Ausgangspunkt für realistische Planung; viele Teams stellen fest, dass 70-75 % für ihre Umgebung genauer ist.

Manager-Zeit nicht einrechnen. Manager-Track-Arbeit (Hiring, 1:1s, Performance-Gespräche, bereichsübergreifende Koordination, Administration) ist kein "Overhead". Es ist echte Arbeit, die echte Stunden kostet. Ein Manager, der das in der Kapazitätsplanung nicht berücksichtigt, über-committet routinemäßig auf Projektarbeit und kämpft dann darum, das Defizit aufzuholen.

Teilzeit- oder Split-Role-Teammitglieder ignorieren. Wenn jemand 40 % seiner Zeit bei einem anderen Team verbringt, beträgt seine effektive Kapazität für Ihren Sprint 60 % seiner Arbeitsstunden minus seinem Overhead. Entsprechend planen. Das klingt offensichtlich, wird aber konsistent übersehen.

Den Kapazitätsplan erstellen und dann nicht mehr darauf zurückgreifen. Die häufigste Fehlerform für Teams, die zu Sprintbeginn gut Kapazitätsplanung betreiben, ist, dass niemand ihn wieder anschaut, bis zum Retrospektive. Überprüfen Sie den Kapazitätsplan zur Sprintmitte. Wenn jemand die verfügbaren Stunden zu überschreiten droht, wollen Sie das am Dienstag wissen, nicht am Freitag.

Kapazitätsplanung als Performance-Metrik nutzen. Kapazitätsplanung ist ein Planungswerkzeug, kein Accountability-Tool. Wenn Teammitglieder lernen, dass wenige verfügbare Stunden zu Performance-Gesprächen führen, manipulieren sie die Eingaben, und Sie verlieren das ehrliche Bild, das Sie brauchen. Die Deloitte-Studie zu psychologischer Sicherheit im Performance Management bestätigt dieses Muster: Teams, in denen Personen befürchten, dass ehrliche Berichte zu Sanktionen führen, melden Probleme systematisch zu wenig, und erzeugen genau den organisatorischen blinden Fleck, den Kapazitätsplanung verhindern soll.

Kapazitätsplanung mit Ihrem Priorisierungsprozess verknüpfen

Kapazitätsplanung und Priorisierung sind die zwei Seiten derselben Sprint-Commitment-Entscheidung. Beide brauchen Sie, um die Frage zu beantworten: „Was kann dieses Team in diesem Sprint wirklich leisten?"

Ihre Priorisierungsrahmen sagen Ihnen, welche Aufgaben am wichtigsten sind. Kapazitätsplanung sagt Ihnen, wie viele davon das Team übernehmen kann. Die Schnittmenge beider ist das Sprint-Commitment.

Wenn die Kapazität geringer ist als üblich (jemand fehlt, eine große Code-Review-Woche, ein Partnerteam braucht Unterstützung), wird die Priorisierung wichtiger, nicht weniger. Ein Sprint mit knapper Kapazität ist genau dann, wenn die Disziplin, „wir erledigen die drei wichtigsten Aufgaben und sonst nichts" zu sagen, am meisten zählt.

Und wenn Sie Ihre Projekt-Kickoffs durchführen, sollte die Kapazitätsprüfung vor dem Kickoff stattfinden, nicht danach. Es ist sehr schwer, sich auf einen Zeitplan und Umfang zu einigen, wenn Sie nicht wissen, wie viel Kapazität das Team in den relevanten Sprints hat. Erstellen Sie zuerst das Kapazitätsbild, führen Sie dann das Umfangsgespräch.

Die wöchentlichen Status-Updates sind der Ort, an dem Kapazitätsüberraschungen in Echtzeit kommuniziert werden. Wenn die committed work eines Sprints aufgrund eines ungeplanten Interrupts gefährdet ist, wird das im Status-Update kommuniziert: klar und frühzeitig, nicht am Sprintende.

Wie ehrliche Kapazität aussieht

Ein ehrlicher Kapazitätsplan wird nicht alle glücklich machen. Stakeholder, denen gesagt wurde, das Team könne zehn Aufgaben pro Sprint liefern, werden überrascht sein, wenn die ehrliche Zahl sechs ist.

Aber die ehrliche Zahl ist auch die reale Zahl. Und reale Zahlen, konsequent kommuniziert, schaffen Vertrauen auf eine Art, wie optimistische Zahlen gefolgt von konsistenten Verfehlungen es nie können.

Das Ziel ist nicht, das Commitment zu minimieren. Es ist, Commitments einzugehen, die das Team tatsächlich einhalten kann, mit Qualität, ohne Burnout und mit Transparenz darüber, wo die Grenzen liegen. Wenn das Team konsequent liefert, was es committet, hören Stakeholder auf, das System zu manipulieren, um mehr Aufgaben in den Sprint zu bringen. Die Gartner-Studie zur Performance von Engineering-Teams ergab, dass Liefervorhersagbarkeit, also das konsequente Liefern des Committed, das vertrauensbildendste Verhalten zwischen Engineering-Teams und Business-Stakeholdern ist und weit vor dem reinen Output-Volumen rangiert. Die Verhandlung wird rational statt politisch.

Ehrliche Kapazitätsplanung dauert, sobald das Format steht, etwa 20 Minuten pro Sprint. Die Kosten des Nicht-Handelns (Sprint-Misses, Burnout, Vertrauensverlust, der Backlog an Nacharbeit) sind um Größenordnungen höher. Für verteilte Teams kommt noch eine weitere Schicht hinzu: der Zeitzonens-Overhead, Overlap-Window-Stunden und Zeit für async-Übergaben gehören ebenfalls in die Kapazitätsberechnung.

Stunden zählen. Puffer einbauen. Zum Sprintstart prüfen. Überzuteilung offen kennzeichnen. Das ist alles.

Weiterlesen: Das vollständige Team Productivity Playbook enthält weitere Leitfäden für Teams, die vorhersagbar liefern und klar kommunizieren. Verwandte Artikel: focus blocks auf Team-Ebene, das Teamnormen-Gespräch, das Sie vermieden haben und ROI von KI-Workforce-Transformation für CFOs.