„Können Sie einen Sprint-Report zusammenstellen?" bedeutet meist, dass jemand in einfachen Worten wissen möchte, ob das Team getan hat, was es angekündigt hat. Das ist eine engere Frage, als es klingt: das meiste, was am Ende in einem Sprint-Report landet, ist entweder ein Burndown-Chart, das niemand genau liest, oder eine Stichpunktliste, die am Morgen des Reviews aus dem Gedächtnis getippt wurde. Keines von beiden beantwortet tatsächlich „haben wir geliefert, was wir zugesagt haben", was die eigentlich lohnenswerte Frage ist.
Was ein Sprint-Report tatsächlich braucht
Auf das Wesentliche reduziert, braucht ein Sprint-Report fünf Dinge: was das Team zu Beginn des Sprints zugesagt hat (nicht das, womit es am Ende dastand: das sind unterschiedliche Zahlen, sobald sich der Umfang verschiebt); was tatsächlich geliefert wurde; was übertragen wurde und warum; wie stark sich der Umfang nach Tag eins verändert hat; und ein gewisses Gefühl dafür, wie lange gelieferte Arbeit tatsächlich gedauert hat, nicht nur, wie viel davon es gab. Ein Report, der den Tag-eins-Ausgangswert auslässt und nur den finalen Inhalt des Sprints zeigt, kann eine verfehlte Lieferung nicht von Scope Creep unterscheiden: von außen sehen beide identisch aus, wenn der Tag-eins-Schnappschuss nicht aufbewahrt wurde.
Sprint-Zusammenfassung: ein Team, ein Sprint
Das ist die Grundform der Sprint-Zusammenfassung von Agile Gauge. Sie wählt einen Sprint aus, den aktuellen, sofern dieser echte Aktivität aufweist, oder sie sucht rückwirkend durch die letzten sechs abgeschlossenen Sprints nach einem, der das tut, und zeigt Zuverlässigkeit der Zusage, Geliefert, Übertrag, In Bearbeitung, Umfangsänderung sowie die mediane Zykluszeit und die Zykluszeit im 85. Perzentil für die abgeschlossenen Items dieses Sprints, jeweils als anklickbare Statistikkarte.
Woher „zugesagt" tatsächlich kommt
Zuverlässigkeit der Zusage bedeutet nur etwas, wenn „zugesagt" ehrlich gemessen wird. Die Sprint-Zusammenfassung definiert es als das, was der Sprint am Ende seines ersten Tages enthielt: gelesen aus der eigenen Historie von Azure DevOps, sofern verfügbar, und andernfalls rekonstruiert, indem die Sprint-Zuordnungshistorie jedes Items nachvollzogen wird (üblich bei Daten, die aus anderen Systemen importiert wurden). Die Seite gibt offen an, welche Methode sie verwendet hat. Kann keine der beiden Methoden einen echten Tag-eins-Schnappschuss ermitteln, werden Zuverlässigkeit der Zusage und Übertrag gar nicht erst angezeigt, statt stillschweigend auf den aktuellen Inhalt des Sprints zurückzugreifen: eine Zahl, die auf „was gerade im Sprint ist" basiert, läge unabhängig davon, was tatsächlich passiert ist, nahe an 100 %, was schlimmer ist als gar keine Zahl.
Gelieferte und zugesagte Items geteilt durch zugesagte Items ergibt die Zuverlässigkeit der Zusage in Prozent; Items, die vollständig aus Azure DevOps entfernt wurden, werden auf beiden Seiten ausgeschlossen, da ein Team weder für vom Business zurückgezogene Arbeit belohnt noch bestraft werden sollte. Ein Item zählt weiterhin als geliefert, wenn es bis zu 24 Stunden nach dem eigentlichen Sprintende abgeschlossen wurde, da die meisten Teams das letzte Item oder zwei erst am Morgen nach dem Review abschließen. Die Umfangsänderung ist (nach Tag eins hinzugefügte Items plus nach Tag eins entfernte Items) geteilt durch die Gesamtzahl der Items: ein Item, das sowohl hinzugefügt als auch später wieder entfernt wurde, zählt in keinem der beiden Fälle.
Jede Zahl mit den tatsächlichen Items belegen
Eine Zahl in einem Sprint-Report, die im Raum nicht hinterfragt werden kann, ist es nicht wert, gezeigt zu werden. Jede Statistikkarte in der Sprint-Zusammenfassung öffnet die genauen dahinterliegenden Items: Zugesagt, Geliefert, Übertrag, In Bearbeitung sowie die Gruppen Hinzugefügt und Entfernt der Umfangsänderung jeweils getrennt, und jedes Item in diesen Listen öffnet sich weiter zu seiner eigenen Zykluszeit, seinem Weg durch die zugeordneten Workflow-Stufen Ihres Teams und einem direkten Link nach Azure DevOps. „Der Übertrag war in diesem Sprint hoch" wird so zu einer konkreten Liste, welche Items übertragen wurden und warum, statt zu einer Zahl, der man einfach glauben muss.
Wenn der Report für ein Meeting ist, nicht nur für einen Bildschirm
Die Sprint-Zusammenfassung ist dafür gebaut, am Bildschirm gelesen zu werden, wobei man jeweils über eine Auswahl zu einem anderen Sprint wechselt. Wenn der Report vor einem Raum präsentiert werden muss: einem Sprint Review, einer Retrospektive, deckt die Retro-Momentaufnahme von Agile Gauge ähnliches Terrain ab, mit sechs bewerteten KPIs gegenüber Zielen, die Ihr Team selbst festlegt, sowie einem Drucklayout, das auf eine Handvoll Seiten passt, statt eine von Hand erstellte Foliensammlung zu benötigen. Beide Ansichten teilen sich dieselben zugrunde liegenden Berechnungen, sodass sich eine Zahl nicht verändert, je nachdem, von welchem Bildschirm aus jemand sie geöffnet hat.
Was das hier nicht abdeckt
Der allererste Sprint eines Teams oder ein Team ganz ohne Sprint-Historie zeigt „noch keine Sprints" statt erfundener Zahlen. Ein sehr großer Sprint, der aus der Item-Historie rekonstruiert statt direkt aus Azure DevOps gelesen wurde, kann gelegentlich ein paar Verschiebungen bei der Wiederherstellung übersehen, was die Zuverlässigkeit etwas großzügiger erscheinen lassen kann, als sie sein sollte: die Seite teilt Ihnen mit, wenn sie die rekonstruierte Methode verwendet hat, sodass dieser Vorbehalt sichtbar bleibt, statt verborgen zu sein. Und jede Zahl auf der Seite ist bereits nach den Work-Item-Typen gefiltert, die Ihre Organisation so konfiguriert hat, dass sie in die Metriken einfließen; bis das eingerichtet ist, wird jeder Typ berücksichtigt.
Der Weg dorthin
Für die Sprint-Zusammenfassung muss zunächst eine Sache eingerichtet sein: die Zuordnung der Workflow-Stufen Ihres Teams in der Konfiguration, damit Agile Gauge weiß, welche Ihrer Status als begonnen und welche als abgeschlossen zählen. Sobald das eingerichtet ist, liest die Sprint-Zusammenfassung Ihre Azure-DevOps-Historie und erstellt den Report in dem Moment, in dem Sie den Bildschirm öffnen: nichts zu exportieren, nichts zweimal einzutippen und nichts, das zwischen einem Sprint Review und dem nächsten veraltet.
Agile Gauge startet bei 20 $ im Monat für bis zu 2 Benutzer. Starten Sie eine kostenlose 14-tägige Testversion: mit vollem Funktionsumfang, keine Kreditkarte erforderlich.