Praxis der Anwendung von Cumulative Flow im Kontext von Scrum und SAFe

In diesem Artikel plane ich zu erzählen, wie wir in unserer Praxis das Cumulative Flow Chart in Scrum im Arbeitsprozess nach dem Framework SAFe

Ich beginne wohl mit einem Link auf diesen Artikel - hier ist meiner Meinung nach ihr Zweck in der Standardform gut beschrieben, ich empfehle, ihn vor dem Lesen meines Artikels zu studieren. Unten beschreibe ich, wie wir sie für den Scrum-Prozess angepasst haben (ursprünglich wird sie in Kanban verwendet) und welche Probleme sie uns bei der Arbeit nach Sprints zu lösen hilft.

Früher habe ich in dem Artikel über Burn Down Charts bereits gesagt, dass wir dort das Auftauchen neuer Arbeit und das Abbrennen alter Arbeit sehen. Das Problem des Burn Down Chart ist, dass wir im Gegensatz zum Cumulative Flow Chart darauf nicht die Bewegung der User Stories durch die Status sehen. Wenn wir jedoch die Bewegungen durch die Status im Cumulative Flow Chart beobachten, beginnen wir tägliche Veränderungen zu sehen (das Burn Down Chart kann sich mehrere Tage nicht ändern und in manchen Kontexten kann das durchaus normal sein) und können feinere Probleme bemerken.

So könnte das in der Dynamik aussehen (auf dem Bild ist ein Diagramm, das auf realen Daten basiert).

In diesem Beispiel sehen wir Folgendes

• In den ersten 7 Tagen des Sprints befindet sich im Testing ein sehr geringer Arbeitsumfang und er ändert sich nicht
• Aus DOR (hier ist es ein Entwurf) gehen die User Stories recht gleichmäßig in die Arbeit über - das ist gut.
• Ebenso wie beim Burn Down sehen wir, dass gemäß dem Trend die User Stories nicht bis zum Ende des Sprints erledigt sein werden

Diese 3 Beobachtungen führen zusammengenommen zu folgender Schlussfolgerung. Hier hätte der Scrum Master offensichtlich schon in frühen Phasen (etwa am zweiten bis dritten Tag des Sprints) auf die Schicht "Testing" achten müssen, die zu klein ist und sich zu lange nicht ändert (sich vergewissern, was die Ursache ist). Man kann vermuten, dass der Arbeitsumfang, der für das Testing bereit ist, aus irgendwelchen Umständen nicht getestet werden kann, aber dann bedeutet das, dass die Tester untätig sind, und das heißt, man sollte ihnen zumindest beim nächsten Standup aufmerksamer zuhören.

Wenn wir über die Anwendungspraxis sprechen, so veröffentliche ich zum Beispiel täglich im Team-Chat alle Metriken vor dem Standup mit Erwähnung des gesamten Teams.

Im Allgemeinen sollte man nicht vergessen, dass die Metriken trotzdem richtig interpretiert werden müssen. In der Lage sein, wirklich systemische Probleme zu sehen, wenn es sie gibt, und nicht als Probleme wahrzunehmen, was in Ihrem Kontext sogar ein positives Zeichen sein kann