Agil, Berichtswesen, Kommunikation, Projektmanagement, Scrum

Der Sprintbericht

Im Scrum wird zu jedem Sprintende sowohl der Projektfortschritt überprüft als auch nach Verbesserungsmaßnahmen für den Entwicklungsprozess gesucht. Die erzielten Ergebnisse sowie die Hindernisse auf dem Weg zur Spitzenleistung finden Eingang in einen Sprintbericht

Der Bericht schafft Transparenz für alle Beteiligten. Er informiert regelmäßig und objektiv. Nicht nur der Informationsfluss an das Management, sondern auch die teaminterne und die teamübergreifende Kommunikation wird durch diesen Bericht unterstützt.

Der Sprintbericht dient der Kommunikation von Messwerten. So, wie das Messen des Projektfortschrittes anhand fertiggestellter Features zu einer Ausrichtung des Teams dahingehend führt, Features auszuliefern, so wird sich die umgebende Organisation an den Inhalten des Sprintberichtes ausrichten. Damit fällt dem Autor des Berichtes eine aktive und organisationsgestaltende Rolle zu.

Der Bericht ist so kurz wie möglich und er wird zwischen dem Product Owner, dem Scrum Master und dem Team abgestimmt, bevor er einem weiteren Personenkreis zugänglich gemacht wird. Der Bericht wird direkt nach dem Sprint Review und der Sprint Retrospektive erarbeitet und spätestens am darauffolgenden Tag fertiggestellt. Für einen klaren Informationsstatus wird der Bericht an zentraler Stelle abgelegt, so dass er für alle Beteiligten jederzeit einsehbar ist. In einer Organisation mit mehreren Scrum Teams sollten die Sprintberichte einem einheitlichen Aufbau folgen.

Im Bericht wird wenig Augenmerk auf die Planungsebene gelegt, sondern vielmehr besteht der Schwerpunkt in einer Bestandsaufnahme beobachteter Fakten.

Das steht drin
Kontext

  • Der Name des Produktes oder der Komponente, für die das Scrum Team arbeitet.
  • Der Name des Product Owners und des Scrum Masters.
  • Die Sprintnummer und der Zeitraum des vergangenen Sprints sowie das Datum des Berichtes.
  • Der Name des Berichterstellers (also der Scrum Master oder der Product Owner).
  • Die Mitglieder des Teams mit ihren Rollen.

Die vergangenen Sprints

  • Der Arbeitsfortschritt (Product Burndown) und die Arbeitsgeschwindigkeit (Velocity).
  • Eine Verlaufslinie der Mitarbeiterkapazität lässt sich dem Arbeitsfortschritt gegenüberstellen. Wenn bestimmte Kapazitäten, wie zum Beispiel die Verfügbarkeit der Fachexperten, nicht ausreichend sind, können die Kapazitäten dieser Rollen mit einer separaten Verlaufslinie in einer anderen Farbe dargestellt werden.
  • Zusätzlich kann eine Information zum Budgetverbrauch und zum Zeitverbrauch enthalten sein.

Der letzte Sprint

  • Was war das übergeordnete Ziel des Sprints (Sprint Goal). Wurde das Sprintziel erreicht?
  • Welche konkreten Funktionen mit welchem Gewicht (Story Points) wurden ausgeliefert?
  • Welche Kapazität hatte das Team zur Erbringung der Leistung zur Verfügung, ggf. nach Teamrollen untergliedert.
  • Welche Hindernisse wurden beseitigt? Welche Verbesserungsmaßnahmen wurden umgesetzt?
  • Welche Hindernisse sind neu entstanden bzw. bestehen noch immer und welche Verbesserungsmaßnahmen wurden aus dem vergangenen Sprint abgeleitet? Hierzu gehört auch die Kultivierung positiven Verhaltens (die „Plus“ Themen aus einer Plus-Delta-Retrospektive, [Derby und Larsen 2006:116] ).

Der nächste Sprint

  • Das übergeordnete Sprintziel (Sprint Goal) und die geplanten Verbesserungsmaßnahmen sowie die Verstärkung positiver Effekte werden dargestellt.
  • Konkret geplante Features sollten nur dargestellt werden, soweit diese bei der teamübergreifenden Kommunikation für andere Teams wesentlich sind.

Änderungen des Product Backlog

  • Größere Änderungen des Product Backlog werden kurz erläutert und begründet.

Architektur- und Fachentscheidungen

  • Falls Architektur- oder Fachentscheidungen [Schneider 2011] getroffen wurden, sind diese im Bericht referenziert.

Das steht nicht drin
Auf einen Ampelstatus kann normalerweise verzichtet werden. Ein solcher Status ist eine starke Reduktion und häufig fehlen eindeutige Kriterien zur Begründung der Statuswerte. Gerade bei einem Ampelstatus lässt sich oft beobachten, dass der Status während der Projektlaufzeit eher als unkritisch (grün) eingestuft wird und kurz vor dem Liefertermin kritisch wird (also gelb oder gar rot). Ein solcher Status hat keine Aussagekraft, so dass auf dieser Grundlage ein Projekt auch nicht gesteuert werden kann. Die Fakten des Sprintberichtes (Arbeitsfortschritt, Arbeitsgeschwindigkeit, Zeitverbrauch und ggf. Budgetverbrauch) besitzen genug Aussagekraft für die kontinuierliche Projektbewertung und die Ableitung von Entscheidungen.

Weitgehende und detaillierte Zukunftsplanungen gehören nicht in den Sprintbericht.

Manchmal kann es in der Sprint Retrospektive zu persönlichen Konflikten kommen. Diese Form des Konfliktes wird im Sprintbericht nicht behandelt. Trotz aller angestrebten Transparenz muss die Retrospektive in diesen Fällen ein geschützter Raum sein, der dem Team erlaubt, zunächst für sich Klarheit zu finden.

Zusammenfassung

Inhalte des Sprintberichts

Referenzen
[Derby und Larsen 2006] Esther Derby und Diana Larsen, Agile Retrospectives: Making Good Teams Great, Pragmatic Programmers, 2006

[Schneider 2011] Ulf Schneider, Architektur und Fachentscheidungen, 2011, siehe: https://allesagil.net/2011/07/27/architektur-und-fachentscheidungen/

Advertisements
Standard