„Say/do-Verhältnis" ist eine grobe, aber nützliche Idee: Von dem, was das Team angekündigt hat zu tun, wie viel hat es tatsächlich getan? Das Problem ist, dass sich das leicht unehrlich messen lässt, ohne dass das beabsichtigt ist. Wird „angekündigt" als das gelesen, was der Sprint zufällig zu dem Zeitpunkt enthält, an dem jemand nachschaut, wird still mitten im Sprint hinzugefügter Umfang so gezählt, als wäre er Teil des ursprünglichen Plans gewesen, und ein Team, das zusätzliche Arbeit übernommen und das meiste davon abgeschlossen hat, kann identisch aussehen wie ein Team, das ehrlich zugesagt und alles geliefert hat. Die Zahl bedeutet nur dann etwas, wenn „zugesagt" an einem echten Zeitpunkt verankert ist, dem Sprintbeginn, und nicht im Nachhinein neu definiert wird.
Warum der Tag-eins-Ausgangswert die ganze Sache ist
Zuverlässigkeit der Zusage ist geliefert-und-zugesagt-Items geteilt durch zugesagte Items, wobei „zugesagt" das ist, was der Sprint am Ende seines ersten Tages enthielt. Ohne diesen festen Punkt sehen verfehlte Lieferung und Scope Creep von außen gleich aus: ein Sprint, der zehn neue Items hinzugefügt und acht davon abgeschlossen hat, und ein Sprint, der acht Items zugesagt und alle geliefert hat, ergeben dieselbe finale Item-Anzahl, sind aber völlig unterschiedliche Sprints. Agile Gauge liest den Tag-eins-Schnappschuss aus der eigenen Sprint-Zuordnungshistorie von Azure DevOps, sofern verfügbar, und rekonstruiert ihn andernfalls, indem die Historie jedes Items nachvollzogen wird: und gibt offen an, welche Methode verwendet wurde, da die rekonstruierte Methode bei einem ungewöhnlich großen Sprint gelegentlich eine Verschiebung übersehen kann.
Über mehrere Teams hinweg: der Sprint-Zusage-KPI von Flow-Gesundheit
Für alle, die mehr als ein Team vergleichen, bewertet die Flow-Gesundheit-Ansicht von Agile Gauge Sprint-Zusage als einen von sechs unabhängigen KPIs über ein benanntes Team-Set hinweg, ohne dass darüber eine gemischte Gesamtnote sitzt. Jedes Team landet auf seinem eigenen Status gegenüber einem Standardziel von 80 % oder besser, und die Kachel trägt einen klaren Satz wie „3 von 6 Teams am Ziel", statt eine einzelne Zahl, die verbirgt, welche Teams tatsächlich zu kämpfen haben. Ein Klick auf die Kachel öffnet die genauen dahinterliegenden Items für das Team, das Sie prüfen möchten.
Ein Team, ein Sprint: dieselbe Zahl in der Sprint-Zusammenfassung
Wenn es im Gespräch um einen bestimmten Sprint geht statt um ein Set von Teams, zeigt die Sprint-Zusammenfassung dieselbe Berechnung als Statistikkarte Zuverlässigkeit der Zusage, neben Übertrag, Umfangsänderung und Zykluszeit für denselben Sprint. Items, die vollständig aus Azure DevOps entfernt wurden, werden auf beiden Seiten des Verhältnisses ausgeschlossen, sodass ein Team weder für vom Business zurückgezogene Arbeit belohnt noch bestraft wird, und ein Item zählt weiterhin als geliefert, wenn es bis zu 24 Stunden nach dem eigentlichen Sprintende abgeschlossen wurde: die meisten Teams schließen das letzte Item oder zwei erst am Morgen nach dem Review ab, und diese Kulanzfrist bewahrt die Zahl davor, normales Timing an der Sprintgrenze zu bestrafen.
Wie es aussieht, wenn es nichts Ehrliches zu zeigen gibt
Kann weder die direkte Historie noch die Rekonstruktion einen echten Tag-eins-Schnappschuss für einen Sprint ermitteln, werden Zuverlässigkeit der Zusage und Übertrag gar nicht erst dargestellt: ein Panel erklärt stattdessen, warum. Die Alternative wäre, die aktuelle Zusammensetzung des Sprints als „zugesagt" zu behandeln, was die Zuverlässigkeit unabhängig davon, was im Sprint tatsächlich passiert ist, nahe 100 % und den Übertrag nahe 0 % erscheinen lässt. Eine fehlende Zahl ist eine ehrlichere Antwort als eine schmeichelhafte, die auf einer falschen Annahme beruht.
Eine Zahl, die sich manipulieren lässt, wenn man sie isoliert betrachtet
Das Say/do-Verhältnis hat eine bekannte Schwäche: Ein Team, das eine schmeichelhafte Zahl möchte, kann einfach weniger zusagen, als es zu liefern erwartet, und dann jeden Sprint zuverlässig aussehen, ohne tatsächlich etwas an seiner Arbeitsweise zu ändern. Zuverlässigkeit der Zusage allein kann ein wirklich sich verbesserndes Team nicht von einem Sandbagging-Team unterscheiden: sie braucht Begleitung. Sie zusammen mit Gelieferter Umfang (wie viel von allem, geplant oder nicht, in diesem Sprint fertig wurde) und Netto-Änderung zu lesen, zeigt den Unterschied: Ein Team, das absichtlich unter seinen Möglichkeiten zusagt, neigt dazu, viel „zusätzlich" gelieferten Umfang über das ursprünglich Geplante hinaus zu zeigen, was ein anderes Muster ist als bei einem Team, dessen Planung wirklich eng ist. Flow-Gesundheit zeigt genau aus diesem Grund beide Zahlen nebeneinander, statt Sprint-Zusage als eine isoliert lesbare Zahl darzustellen.
Ein Ziel setzen, dem Ihr Team tatsächlich zugestimmt hat
Der Standardwert von 80 % ist ein Ausgangspunkt, kein Ziel, dem notwendigerweise schon jemand zugestimmt hat. Jeder KPI, den Flow-Gesundheit bewertet: Sprint-Zusage eingeschlossen, hat ein pro benanntem Team-Set editierbares Ziel, das über das eigene Ziele-Panel von Flow-Gesundheit gesetzt und automatisch mit der Retro-Momentaufnahme für jeden unter diesem Set betrachteten Sprint geteilt wird. Ein Team, das eine strengere oder lockerere Messlatte als 80 % möchte, kann eine setzen, und ein Set vor dem Ändern seiner Ziele zu duplizieren, ist ein schneller Weg, einen anderen Schwellenwert auszuprobieren, ohne das zu stören, was alle anderen gerade betrachten.
Der Weg dorthin
Für die Zuverlässigkeit der Sprint-Zusage muss die Workflow-Stufen-Zuordnung Ihres Teams in der Konfiguration gesetzt sein, damit Agile Gauge weiß, welche Status als abgeschlossen zählen. Der Vergleich über Teams hinweg benötigt außerdem ein benanntes Team-Set: eine gespeicherte Liste von bis zu 12 Teams, aus der sowohl Flow-Gesundheit als auch Retro-Momentaufnahme auswählen können. Sobald beides eingerichtet ist, wird die Zahl jedes Mal live gelesen, wenn einer der beiden Bildschirme geöffnet wird.
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.