Teambook für IT- und Software-Teams

Wie Entwicklungsteams Teambook für realistische Sprintplanung nutzen

Sprints scheitern oft nicht, weil der Code schwer ist, sondern weil die „100 Stunden Kapazität“, von denen Sie dachten, sie zu haben, tatsächlich nur 60 Stunden betragen – wegen eines Feiertags, einer Krankheit oder weil ein Entwickler für die Behebung eines dringenden Bugs in einem anderen Projekt abgezogen wird.

Teambook überbrückt die Lücke zwischen Ihrem Jira/DevOps-Backlog und den tatsächlichen Menschen, die die Arbeit erledigen.

Schritt 1: Realistische Basiskapazität festlegen

Bevor Sie Tickets in einen Sprint ziehen, müssen Sie wissen, wie viel Zeit Ihr Team tatsächlich zur Verfügung hat.

In Teambook:

Legen Sie den Arbeitsplan jedes Entwicklers in dessen Benutzerprofil fest.
Lassen Sie Teambook automatisch berücksichtigen:
- Feiertage
- Teilzeitverträge
- Geplante Abwesenheiten
Setzen Sie eine realistische Auslastungsrate fest, zum Beispiel:
- 85 % ist ein allgemein akzeptiertes Ziel
- Das bedeutet, dass 15 % für nicht produktive Aufgaben verwendet werden So erhalten Sie eine echte Basiskapazität, keine theoretische.

Schritt 2: Überlastung erkennen, bevor der Sprint beginnt

Nutzen Sie die Benutzeransicht im Planungsmodul, um sofort Verfügbarkeiten (weiße Zellen) und Überlastungen (rote Zahlen) zu erkennen.

Wenn jemand rot wird, können Sie sofort:

Arbeit an einen Entwickler mit verfügbarer Kapazität neu zuweisen, indem Sie die betreffenden Buchungen einfach per Drag & Drop zu einem anderen Benutzer ziehen (Sie können die Liste nach Fähigkeiten/Tags filtern).
Den Umfang oder die Dauer einer Aufgabe reduzieren.
Arbeit in den nächsten Sprint verschieben, indem Sie die betreffenden Buchungen einfach per Drag & Drop auf ein späteres Datum ziehen. Das ersetzt die Gewohnheit von Tabellenkalkulationen, bei denen Überlastung erst nach dem Scheitern des Sprints bemerkt wird.

Schritt 3: Zeit für „Business as Usual“-Arbeit schützen

IT- und Software-Teams haben immer unsichtbare Arbeit wie tägliche Stand-ups, Code-Reviews, interne Meetings oder ungeplante Hotfixes.

Wenn Sie dies ignorieren, wird Ihre Velocity immer überschätzt.

Beste Praxis in Teambook:

Erstellen Sie interne Projekte (markieren Sie sie als nicht abrechenbar).
Buchen Sie eine feste Zeitmenge pro Entwickler, z. B. 1 Stunde pro Tag, die den entsprechenden internen Projekten zugewiesen wird. Verwenden Sie dafür wiederkehrende Buchungen. So wird sichergestellt, dass die Sprintkapazität die tatsächliche Programmierzeit widerspiegelt, nicht die gesamten Arbeitsstunden.

Schritt 4: Realitätscheck nach dem Sprint durchführen

Am Ende des Sprints bitten Sie Ihre Kollegen, ihre Zeiterfassungsbögen auszufüllen. Vergleichen Sie anschließend die geplante und die tatsächliche Zeit in den Berichten.

Worauf Sie achten sollten:

40 Stunden geplant, 30 Stunden erfasst = Kapazitäts- oder Schätzungslücke.
Wiederholte Lücken über mehrere Sprints hinweg = strukturelles Problem, kein Einzelfall.

Wie Sie diese Daten nutzen:

Integrieren Sie sie in Sprint-Retrospektiven.
Passen Sie Story-Point-Schätzungen oder Arbeitsbelastungsannahmen an.
Verfeinern Sie BAU-Zuweisungen (Business As Usual) bei Bedarf. Mit der Zeit wird die Sprintplanung so von einer Schätzung zu einer Feedbackschleife.

Wie sieht Erfolg aus?
Teams, die Teambook für die Sprintplanung nutzen, stellen typischerweise fest:

Weniger verpasste Sprint-Zusagen.
Vorhersehbarere Velocity.
Frühere Erkennung von Überlastung.
Besseres Vertrauen zwischen Produkt-, Entwicklungs- und Stakeholder-Teams. Sprintpläne werden zu etwas, das das Team tatsächlich liefern kann, nicht zu etwas, das man hofft, dass es funktioniert.

Nächste Schritte

Um die Sprintplanung zuverlässiger zu gestalten:

Überprüfen Sie den Arbeitsplan und die Zuweisungen jedes Teammitglieds, um sicherzustellen, dass sie die Realität widerspiegeln, nicht nur Annahmen.
Erstellen Sie interne Projekte, um nicht produktive Stunden zu buchen, und wenden Sie solche Buchungen konsistent auf alle Sprints an.
Nutzen Sie die Benutzeransicht während der Sprintplanung, um Überlastung zu beheben, bevor der Sprint beginnt.
Vergleichen Sie geplante und tatsächliche Zeit am Ende jedes Sprints und passen Sie die Kapazitätsannahmen regelmäßig an. Wenn diese Methode konsequent angewendet wird, hilft sie Teams, auf der Grundlage der tatsächlichen Verfügbarkeit zu planen, anstatt auf optimistischen Schätzungen.