Erfahrungsgemäß stehen die Teammitglieder nie zu 100% ihrer Anwesenheit für einen Sprint zur Verfügung. Je nach Unternehmen liegt die Verfügbarkeit der Mitarbeiter meist zwischen 50% – 80%. Bei der nicht für den Sprint verfügbaren Zeit kann es sich zum Beispiel um Teammeetings, Mitarbeitergespräche oder um regelmäßige Termine mit Vorgesetzten handeln. Besonders in kleinen Unternehmen haben Scrum-Teams oft zusätzliche Wartungsaufgaben oder müssen sich nebenbei um den operativen Betrieb kümmern.
Dies sind alles Nebenschauplätze, die nichts mit dem Sprint zu tun haben und daher von der Verfügbarkeit der Mitarbeiter abgezogen werden müssen. Wir verwenden daher seit vielen Jahren eine Sprintübersicht. Letztendlich, eine Zusammenfassung der wesentlichen Informationen für den anstehenden Sprint.
Sprintübersicht
Zu Beginn des Sprint Planning wird daher gemeinsam mit allen Beteiligten die Sprintübersicht gepflegt, so dass die Inhalte des Sprints geplant werden können und alle ein gutes Gefühl bei der Planung haben. Wenn beispielsweise der einzige Frontend-Developer im Team während des Sprints für eine Woche im Urlaub ist, sollte dem Rechnung getragen werden. Wir erfragen die Verfügbarkeit des Teams mit einer Granularität von einem halben Tag und halten diese Informationen in einer Sprintübersicht (1) fest.
Die Sprintübersicht platzieren wir im Anschluss an das Sprint Planning nahe dem Team Board, wo sie mit der Definition of Done sowie Definition of Ready (2) immer im sichtbaren Bereich hängt. Diese Übersicht wird während des Sprints dauerhaft vom Team gepflegt und enthält u.a. die folgenden Informationen:
- Sprint Name bzw. Sprint Ziel (ggf. eine Sprint Nummer)
- Sprint Zeitraum sowie ggf. der Release-Termin
- Die Velocity
- Das Commitment des Teams nach dem Sprint Planning
- Die Kalenderübersicht inkl. Urlaube, Homeoffice, Feiertage, Events, etc.
- Das Burndown/-up Chart
Mit diesen Informationen lässt sich vor dem Sprint Planning sehr gut die Einschätzung zur Kapazität abbilden, die dann in die Diskussionen zum Sprint und dem Sprint-Backlog einfließen können.
Die Sprintübersicht kann selbstredend auch in digitaler Form einer Sharepoint-Datei, einer Confluence-Seite oder einem Miro-Board gepflegt werden. Zu bedenken dabei ist, dass es sich um ein lebendes Artefakt handelt, dass während des Sprints aktualisierte werden sollte.
Zeitfresser-Übersicht
Wenn bspw. ein achtköpfiges Team, nur zu 50% am Sprint arbeiten kann, ergibt sich daraus rechnerisch eine Verfügbarkeit von lediglich vier Personen. Diese Situation sollten Sie unbedingt als Hindernis behandeln. Die Fokussierung des Teams wird stark beeinträchtigt, und eine Prognose ist nicht möglich, wenn die anderen Tätigkeiten spontan und ungeplant auftreten (z.B. User Support). Durch das aktive Angehen dieses Hindernisses beugen Sie auch Nachfragen des Managements vor, warum das (vermeintlich) achtköpfige, teure Scrum-Team denn so langsam ist und nur so wenig Ergebnisse liefert.
Um die Transparenz über solche „Zeitfresser“ zu erhalten, nutzen wir für die Datenerhebung eine Zeitfresser-Übersicht (3). Dies ist eine einfache Tabelle der Wochentage, in die Teammitglieder Post-its mit Ursachen für auftretenden Störungen und der dafür aufgewendeten Zeit hängen. Spätestens im Daily Scrum sollte diese Übersicht aktualisiert werden. Die dadurch entstehende Dokumentation wird genutzt, um wiederkehrende oder sehr zeitintensive Themen anzugehen und diese bspw. in der Retrospektive zu besprechen.
Während wir die Sprintübersicht laufend nutzen, ist die Zeitfresser-Übersicht oftmals eher temporär hilfreich, um die Ursachen für Unterbrechungen zu visualisieren und diese schnellstmöglich aufzulösen.
Transparenz ist alles
Wir möchten in diesem Zuge auch anregen, Metriken wie den Velocity-Verlauf, vereinbarte Team- oder Daily-Standup-Regeln (4) nahe dem Board aufzuhängen. Oftmals sind Unklarheiten und Fragen so schnell aus dem Weg geräumt.
Der Beitrag wurde im August 2022 aktualisiert.
