Leistungsstarke agile Teams liefern nicht nur Ergebnisse, sondern reflektieren diese auch. Diese Gewohnheit, nach jedem Sprint innezuhalten und zu fragen, was gut gelaufen ist, was nicht und was wir ändern sollten, ist das Herzstück der kontinuierlichen Verbesserung, auch Kaizen genannt: kleine, stetige Anpassungen, die sich Sprint für Sprint summieren. Doch eine gute Retrospektive braucht eine solide Grundlage, nicht nur ein Bauchgefühl. Während wir weiter in agile Arbeitsweisen investieren, möchten wir Ihnen zeigen, wohin wir uns beim agilen Reporting entwickeln. Wir zeigen Ihnen die Sprintberichte, Diagramme, Dashboards und Erkenntnisse, die Ihren Teams die Grundlage für ihre Retrospektive geben und damit Verbesserungen wirklich vorantreiben.
Schnellnavigation:
- Co-Creation mit unserer Community
- Retrospektiven weniger mühsam gestalten
- Sprintberichte
- Sprintziel und Arbeitspaketübersicht
- Burndown-Diagramm
- Burnup-Diagramm
- Velocity-Diagramm
- Fortschrittsdiagramm für Epics
- Diagramm „Neu vs. abgeschlossen“
- Kumulative Flussdiagramme
- Änderungen am Sprintumfang
- Zykluszeit und Durchlaufzeit
- Berichte über Sprints und Portfolios hinweg
- Individualisierung
- Ansätze, die wir im Bereich agiler Berichte prüfen
Co-Creation mit unserer Community
In den vergangenen Monaten haben wir mit Teams gesprochen, die Scrum, Kanban und SAFe im großen Maßstab einsetzen, und genauer betrachtet, wo Reporting an seine Grenzen stößt – besonders bei Teams, die von Werkzeugen wie Jira kommen, wo Berichte oft über viele Plugins verstreut sind. Diese Gespräche haben die Richtung geprägt, die wir unten vorstellen. Wie immer handelt es sich um einen Ausblick auf Konzepte und frühe Prototypen, nicht um einen fertigen Funktionsumfang. Wir teilen ihn früh, weil wir uns Ihr Feedback wünschen, um unsere Entwicklung weiter zu verbessern.
Retrospektiven weniger mühsam gestalten
Das Ziel des neuen Reporting-Konzepts ist einfach: Es soll mühelos erkennbar sein, wie ein Sprint tatsächlich verlaufen ist – ohne Daten in eine Tabellenkalkulation zu exportieren oder drei verschiedene Plugins miteinander zu kombinieren. Berichte sollen die Fragen beantworten, mit denen jede Retrospektive beginnt: Haben wir geschafft, was wir geplant hatten? Wo hat sich Arbeit gestaut? Wie hat sich der Sprintumfang verändert? Werden wir schneller oder langsamer? Und das, ohne dass sich jemand dieses Bild von Hand zusammensetzen muss.
Sprintberichte
Im Zentrum des neuen Konzepts steht der Sprintbericht: eine einzige Ansicht, die zusammenfasst, was geplant war, was abgeschlossen wurde, was mitten im Sprint hinzukam und in den nächsten Sprint übernommen wurde. Statt den Verlauf eines Boards mühselig manuell durchzugehen, kann ein Team nach dem Sprintende eine einzige Seite öffnen und sofort erkennen, wie der Sprint verlaufen ist. Der Sprintbericht stellt damit einen natürlichen Ausgangspunkt für jede Retrospektive dar. Und das natürlich inklusive der visuellen Diagramme, die Sie brauchen, um schnell zu erkennen, welche Bereiche gut liefen und welche vielleicht zusätzliche Aufmerksamkeit erfordern. Selbstverständlich haben Sie auch die Möglichkeit, die Berichte schon während des Sprints einzusehen, um Probleme frühzeitig zu erkennen.
Sprintziel und Arbeitspaketübersicht
Ihr Sprintbericht beginnt mit einem Sprintziel, damit für alle klar ist, worauf der Fokus liegt. Außerdem erhalten Sie einen Überblick über den Zustand des Sprints, der den gesamten Sprintfortschritt und Änderungen am Umfang zeigt.
Burndown-Diagramm
Das klassische Burndown-Diagramm erhält eine Überarbeitung. Es stellt die verbleibende Arbeit – in Story Points, Stunden oder Anzahl der Arbeitspakete – dem Sprintverlauf gegenüber, sodass Teams auf einen Blick sehen, ob sie im Plan, voraus oder im Rückstand sind. Außerdem prüfen wir, wie sich die ideale Fortschrittslinie leichter mit dem tatsächlichen Fortschritt vergleichen lässt, damit Abweichungen – sowohl eine Zunahme als auch eine Abnahme des Umfangs – deutlich erkennbar werden.
Burnup-Diagramm
Für Teams, deren Umfang sich mitten im Sprint verschiebt – und das sind, seien wir ehrlich, die meisten Teams –, planen wir, neben dem Burndown- auch Burnup-Diagramme einzuführen. Statt nur zu zeigen, was noch übrig ist, stellt ein Burnup-Diagramm die abgeschlossene Arbeit und den Gesamtumfang im Zeitverlauf dar und macht so schleichende Umfangserweiterungen (Scope Creep) sichtbar, statt dass man sie erst im Nachhinein bemerkt.
Velocity-Diagramm
Damit Teams künftige Sprints mit mehr Sicherheit planen können, zeigen Velocity-Diagramme die abgeschlossenen Story Points, Arbeitspakete oder die aufgewendete Zeit über die letzten Sprints hinweg an. Es geht nicht darum, jedes Mal eine noch höhere Zahl anzustreben. Es geht darum, Teams ein realistisches, datengestütztes Gefühl für ihren eigenen Durchsatz zu geben, damit die Sprintplanung kein Ratespiel mehr ist und Sie eine verlässliche Grundlage haben, um einen angemessenen Sprintumfang zu planen.
Fortschrittsdiagramm für Epics
Für Teams, die Arbeit auf einer höheren Ebene als einzelnen Sprints verfolgen, planen wir ein Fortschrittsdiagramm für Epics. Diese Ansicht zeigt, wie viele Arbeitspakete oder Story Points innerhalb eines Epics abgeschlossen oder noch offen sind. Statt sich in ein Epic zu klicken und den Status manuell auszuzählen, sehen ein Team oder Stakeholder den Fortschritt eines einzelnen Epics, oder mehrerer Epics nebeneinander direkt auf einen Blick. Das ist besonders nützlich für Teams, die über mehrere Sprints oder Product Increments hinwegarbeiten, bei denen sich ein Epic über Wochen oder Monate erstrecken kann und kein einzelner Sprintbericht das Gesamtbild vermitteln kann.
Diagramm „Neu vs. abgeschlossen“
Für Teams, die einen stetigen Strom eingehender Arbeit bewältigen, wie beispielsweise Support-Tickets, Bugs, ungeplante Anfragen, planen wir ein Diagramm „Neu vs. Abgeschlossen“. Indem neue Arbeit im Zeitverlauf der gelösten Arbeit gegenübergestellt wird, lässt sich leicht erkennen, ob der Arbeitsrückstand abnimmt, konstant bleibt oder still und leise außer Kontrolle gerät.
Kumulative Flussdiagramme
Für Teams, die in Kanban oder einem Scrumban-Ablauf arbeiten, visualisiert das kumulative Flussdiagramm, wie sich Arbeitspakete im Zeitverlauf durch die einzelnen Status bewegen. Breiter werdende Bänder weisen direkt auf Engpässe hin. Wenn beispielsweise der Umfang der Arbeitspakete „In Bearbeitung“ immer weiter ansteigt, ist genau das die Stelle, auf die ein Team schauen sollte.
Änderungen am Sprintumfang
Mit den integrierten Arbeitspakettabellen erhalten Sie schnell einen Überblick über alle Arbeitspakete, die innerhalb eines Sprints abgeschlossen wurden, und welche nicht. Auch die Zunahme und Abnahme des Umfangs wird im Detail aufgeführt.
Zykluszeit und Durchlaufzeit
Wir planen außerdem, die Zykluszeit und die Durchlaufzeit in die Berichtsfunktionen aufzunehmen. Dies sind zwei miteinander verbundene, aber unterschiedliche Kennzahlen zur Geschwindigkeit.
Die Zykluszeit gibt an, wie lange ein Arbeitspaket dauert, sobald tatsächlich mit dessen Bearbeitung begonnen wird, und zeigt, wie zügig das Team vorankommt, sobald die Arbeit aufgenommen wurde.
Die Durchlaufzeit erfasst den gesamten Prozess vom Zeitpunkt, zu dem eine Anfrage erstmals in den Backlog aufgenommen wird, bis zu ihrer Fertigstellung. Damit gibt sie wieder, wie lange der Antragsteller tatsächlich gewartet hat.
Die Differenz zwischen den beiden Werten spricht für sich: Ein großer Unterschied deutet in der Regel eher auf ein Warteschlangen- oder Priorisierungsproblem hin als auf ein Geschwindigkeitsproblem, da der Großteil der Verzögerung bereits auftritt, bevor überhaupt mit der Arbeit begonnen wird. Teams können festlegen, welche Status den Beginn und das Ende jeder Messung markieren, und sehen dann beide Kennzahlen gemeinsam, sodass Retrospektiven das richtige Problem angehen können, anstatt nur Vermutungen anzustellen.
Berichte über Sprints und Portfolios hinweg
Für Organisationen mit mehreren Teams, insbesondere unter SAFe, prüfen wir derzeit Berichte, die Daten über Sprints, Projekte oder ein gesamtes Portfolio hinweg zusammenfassen. Anstatt die Board-Ansichten von sechs Teams einzeln zu überprüfen, könnte ein Programmleiter eine einzige, zusammengefasste Ansicht des Epic-Fortschritts oder des kumulativen Flussdiagrammes einsehen, welches alle Teams eines Produktinkrements umfasst.
Individualisierung
Für die erste Version des agilen Reportings planen wir, eine statische Seite für Sprintberichte bereitzustellen. Durch die Weiterentwicklung geben wir Ihnen die Möglichkeit, die standardmäßigen Sprintberichte anzupassen, sodass Sie nur die Diagramme auswählen, die für Ihr Team relevant sind. Wir planen außerdem, die Projekt-Dashboards zu erweitern und die agilen Diagramme als konfigurierbare Dashboard-Widgets anzubieten.
Ansätze, die wir im Bereich agiler Berichte prüfen
Diese Konzepte stellen unsere Vision für agiles Reporting innerhalb von OpenProject dar. Wir bedanken uns bei allen, die an den Nutzerbefragungen teilgenommen und zu dieser Vision beigetragen haben. Wir würden uns sehr über Ihr Feedback zu den Prototypen freuen, die wir hier veröffentlichen, damit wir die Reporting-Funktionen entsprechend Ihren Anforderungen weiter verbessern können.
Diese Prototypen zeigen, in welche Richtung wir das Reporting in OpenProject weiterentwickeln möchten: näher an die tatsächliche Funktionsweise von Retrospektiven, und nützlich für Teams, die Scrum, Kanban oder SAFe praktizieren. Wir planen, die erste Version der agilen Berichte in Kürze zu veröffentlichen; bleiben Sie also auf dem Laufenden.
