Praxis der Anwendung von Burn Down Charts im Kontext von SAFe und Scrum

In diesem Artikel plane ich zu erzählen, wie wir in unserer Praxis das Burn Down Chart im Arbeitsprozess nach der SAFe-Methodik einsetzen

Ich beginne wohl mit dem Interessantesten. Und zwar damit, dass die Verwendung dieses Diagramms in SAFe keine Besonderheiten gegenüber der Verwendung dieses Diagramms in SCRUM haben sollte. Oder doch?

SAFe unterscheidet sich bei uns durch das Vorhandensein einer Rolle wie RTE, im Gegensatz zu SCRUM, wo es sie nicht gibt. Das Burn Down Chart - ist ein Instrument zur Verfolgung des Arbeitsumfangs im Sprint und es ist in erster Linie für das SCRUM-Team notwendig, und nicht für jemanden von außen, nicht wahr?

So komme ich nun doch dazu, wie wir das Burn Down Chart verwenden, trotz allem, und dabei weiterhin innerhalb des SAFe-Frameworks bleiben.

Ich bin in der Rolle des Scrum Master und bemühe mich, dieses Diagramm täglich für das gesamte Dev Teamhervorzuheben. Das Mittel, das ich verwende, ist der Team-Chat, die Erwähnung des gesamten Teams über "@", ein Screenshot des aktuellen Zustands des Diagramms. Die Erwähnung des gesamten Teams ist ein recht feines Instrument und es ist wichtig, es so selten wie möglich zu verwenden (denn wir Scrum Master sollten dem Team helfen, komfortabel und mit minimal möglicher Ablenkung zu arbeiten, nicht wahr?)

Infolgedessen sieht das Team täglich den aktuellen Zustand des Sprints und ist in der Lage, die folgenden Ereignisse zu verfolgen

• Das Auftauchen ungeplanter Arbeit
• Langes Hängenbleiben von Aufgaben im unerledigten Status
• Übermäßiges Einplanen von Risiken
• Das Verständnis - ob die Arbeit im richtigen Tempo vorangeht

Als Nächstes werde ich versuchen, jedes dieser Ereignisse zu erläutern und Beispiele aus meiner Praxis anzuführen.

Das Auftauchen ungeplanter Arbeit

In diesem Diagramm ist sehr gut zu sehen, wie neue Arbeit entsteht (am zweiten Dienstag des zweiwöchigen Sprints).

Fall aus der Praxis: "Ein Entwickler als Mitglied des Scrum-Teams, das die Agile-Prinzipien teilt, interagiert großartig direkt mit dem Product Owner. Der Product Owner sagt ihm, dass dies hier schnell eingebaut werden muss, du verstehst ja selbst, hier geht es schnell und die Risiken sind minimal.

Der Entwickler ist großartig, er weiß alles über Agile und über die Wichtigkeit der Lieferung von Geschäftswert, er geht und wirft eine Story aus dem Backlog auf das Board, sie wurde vom Team mit 6 SP geschätzt.

Der übrige Teil des Teams (außer dem Entwickler und dem Product Owner) bemerkt dies beim morgendlichen Update des Diagramms. Im Standup entscheidet das Team, wie mit dieser Situation umzugehen ist. Wahrscheinlich wird die Story aus dem Sprint geworfen, dem Product Owner und dem Entwickler macht das Team klar, dass man das so nicht machen kann, der Product Owner kann diese Story bei Bedarf in den nächsten Sprint legen.

Natürlich sollte das Team im Idealfall das Auftauchen neuer Arbeit im Standup auch ohne Diagramm bemerken. Aber das Diagramm ist ein guter Indikator, der die Risiken, eine so wichtige Veränderung für das gesamte Team nicht zu bemerken, auf ein Minimum reduziert.

Hier ist es wichtig zu verstehen, dass das Szenario je nach Reifegrad des Teams unterschiedlich hätte verlaufen können. In starken Teams hätte der Product Owner das kaum so gemacht, und wenn doch, dann hätte er es nicht damit begründet, dass «man das schnell einbauen kann», sondern damit, dass «ich die Wahrscheinlichkeit von 55% schätze, dass wenn man das jetzt einbaut, es unseren Gewinn im nächsten Monat um 20% steigern könnte» oder mit einer anderen messbaren Metrik.

Langes Hängenbleiben von Aufgaben im unerledigten Status

Hier sehen wir, dass die Arbeit sehr lange nicht einmal teilweise abgeschlossen wird. Dies kann auf verschiedene Probleme hinweisen, ich zähle einige davon auf

• Schlechte Aufgabenzerlegung

  Sehr oft sagen Anfänger-Teams, dass eine Zerlegung nicht möglich sei. Bei ihnen brennt alles am letzten Tag ab, die Arbeit lässt sich nicht parallelisieren usw. Natürlich muss daran gearbeitet werden, und der Scrum Master muss dem Team den Wert der Zerlegung erklären.

• Nicht optimal formulierte DOD

  DOD (Definition of Done) – die Beschreibung der Fertigstellungskriterien einer User Story im Sprint. Manchmal gibt es sie gar nicht oder sie sind sehr abstrakt beschrieben. Das kann durchaus ein Problem sein, das natürlich der Scrum Master lösen helfen sollte

Übermäßiges Einplanen von Risiken

In diesem Fall sehen wir eine Situation, in der das Team zu viele Risiken eingeplant hat.

Möglicherweise wurde eine Story zu hoch geschätzt. Möglicherweise ist es ein systemischeres Problem und es ist notwendig, den Arbeitsumfang bei der Sprintplanung zu erhöhen. In jedem Fall ist diese Situation nicht korrekt. Denn das Business hat geplant, dass genau die Aufgaben des Sprints und genau bis zum Ende des Sprints umgesetzt werden. Je nachdem, wie die Abhängigkeiten geplant wurden, wird man hier wahrscheinlich Meetings zur Anpassung der Erwartungen abhalten müssen.

In meiner Praxis war das so, als eine schnellere Lösung gefunden wurde, als bei der Schätzung besprochen wurde. Das ganze Team besprach, welche Story wir bis zum Ende des Sprints abschließen können, und in der Retrospektive einigten wir uns darauf, dass wir versuchen werden, den Code beim Grooming anzusehen. Es stellte sich heraus, dass es genügte, einfach in den Code zu schauen, um zu verstehen, dass die Lösung viel einfacher war.

Verständnis – ob die Arbeit im richtigen Tempo vorangeht

Hier möchte ich auf grafisch ungünstige Darstellungsweisen des Burn Down Chart aufmerksam machen

Im oberen Teil des Bildes ist ein Beispiel für eine nicht besonders gelungene grafische Umsetzung aus zwei Gründen angeführt, die ich unten darlege.

• Das Hinzufügen neuer SP in den Sprint ist nicht erkennbar

  Hier, im oberen Diagramm, ist praktisch nicht erkennbar, dass ungeplante Arbeit hinzugekommen ist. Im unteren ist das anschaulicher.

• Der relative Arbeitsrest wird nicht korrekt dargestellt

  Laut dem oberen Diagramm blieben noch 3 Tage zu arbeiten. Tatsächlich sind es 2, am Wochenende plant vielleicht jemand, sich auszuruhen.

Natürlich mögen manche solche Kleinigkeiten unbedeutend erscheinen. Aber man muss verstehen, dass jedes Mitglied des Teams nur mit einem halben Auge auf dieses Diagramm blickt und es ein Maximum an nützlicher Information vermitteln muss.