Burndown Charts verständlich erklärt

Jasmine

Schön, dass du wieder dabei bist beim Agile Growth Podcast. Heuete geht es um ein Oldschool visuelles Management Tool, nämlich Burnup und Burndown Charts. Wie können wir die als Agile Coach erfolgreich einsetzen? Welchen Nutzen können wir daraus ziehen? Und wie können sie uns helfen, in die Kommunikation zu kommen?

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

Kai

Herzlich willkommen zum Agile Growth Podcast! Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen Agiler Vorgehensweisen in der Praxis einzulösen, ohne IT-Wissen vorauszusetzen. Und heute geht es um grafische Werkzeuge, die einem dabei helfen können, dass man weiß, wo steht man eigentlich in Bezug auf Produktentwicklung, in Bezug auf den Fortschritt eines konkreten Sprints? Da kommt einem vielleicht das Wort Burndown Chart in den Kopf.

Jasmine

Und wenn wir an die Empirie denken, dann haben wir die drei Säulen des empirischen Vorgehens, nämlich die Transparenz schaffen, also 100%-ige Transparenz schaffen über alles, was gut läuft und alles, was nicht so gut läuft, damit wir entsprechend inspizieren können. Das heißt, die richtigen Fragen stellen können, damit wir adaptieren können. Das heißt das Richtige anpassen können. Da helfen einem grafische Werkzeuge einfach ungemein. Und da gibt es natürlich auch noch viel mehr als Burndown Charts.

Jasmine

Wenn wir jetzt aber den Sprint Fortschritt angucken, wenn wir angucken, wie kann es ein Team denn schaffen, sich wirklich selbst zu managen in Hinblick auf zum Beispiel das Sprint Ziel oder das Ergebnis, was am Ende eines Sprints rauskommen soll? Und wie schafft es auch das gesamte Scrum-Team sich selber zu managen in Hinblick auf Produkt-Ziele? Dann sind unserer Meinung nach BurndownCharts eine große Hilfe. Sie sind kein Muss. Also ganz wichtig, du machst auch Scrum, wenn du keine Burndown oder Burnup oder was auch immer Charts machst.

Jasmine

Aber sie helfen manchmal einfach als visueller Marker, den wir zum Beispiel in einem Daily benutzen können.

Kai

Ich habe mal Jeff Sutherland reden hören darüber. Der ist ja so einer der geistigen Väter von Scrum und der war Kampfpilot bei den Amerikanern. Und der hatte dann natürlich die Aufgabe, auf so einem Flugzeugträger im Wasser zu landen. Und wenn man das versucht, dann bist du halt irgendwo in der Luft mit einem Flugzeug und muss halt schauen, dass du aufsetzt, quasi zwischen dem Beginn des Flugzeugträgers und dem Ende. Insofern hast du so einen Korridor Fenster, in dem du landen kannst.

Kai

Und die gleiche Analogie hat er benutzt, um zu überlegen, okay, eigentlich wollen wir doch so ein Sprint, den wir uns vornehmen an Arbeit, zum Beispiel für vier Wochen wollen wir doch auch in so einem Fenster landen, also das wir möglichst im richtigen Korridor dann da unten ankommen, nämlich was ist mit da unten gemeint? Am Anfang vom Sprint haben wir ganz viele Tätigkeiten, Dinge die in der Sprint Planung identifiziert worden sind und die wir erledigen wollen. Und dann wollen wir die Tätigkeiten Stück für Stück abarbeiten, selbst gemanagt innerhalb unseres agilen Teams, um dann am Ende vom Sprint möglichst bei Null raus zu kommen.

Kai

Also dass wir alles gemacht haben, was wir uns vorgenommen haben. Und so eine Grafik nimmt man dann, also da ist die Zeitachse ist dann die x-Achse und auf der y-Achse ist die Anzahl der nicht geschlossenen Tätigkeiten, also der Tasks, die noch offen sind. So ein Ding nennt man dann einen Sprint Task Burndown Chart.

Jasmine

Also das was Kai gerade beschrieben hat, da wo wir die Tasks eintragen und dann auch abtragen, wie viel Tasks haben wir fertig? Das Sprint Task Burndown Chart habe ich persönlich noch nie benutzt. Was ich lieber benutze ist das Sprint Product Burndown Chart, nämlich da, wo wir auf die eine Achse eintragen wie viele Backlogs Einträge im Fall wenn ihr User Stories benutzt wie viele User Stories, aber wie viele Backlogs Einträge wir in unserem Sprint haben. Wir könnten auch natürlich, wenn wir so was wie Story Points benutzen, die Story Points eintragen.

Jasmine

Sollten wir in Mann-Frau Tagen schätzen, können wir auch das eintragen. Aber oft hilft es mir schon auch einfach nur zu sagen: Okay, wir haben sechs, sieben, acht Product Backlog Einträge in unserem Sprint drin. Die trage ich auf der Achse ein. Und dann jedes Mal, wenn ein Produkt Backlogs Eintrag, also eine User Story oder wie auch immer ihr die formuliert fertig ist, dann tragen wir die ab. Das hat mir bis jetzt in den Team-Kontexten meistens genug Sichtbarkeit darüber gegeben

Jasmine

Wie gut sind wir denn unterwegs? Und was ich an der Variante auch immer sehr sehr charmant fand ist, man hat die Team-Zusammenarbeit unglaublich gut gesehen. Oft ist es nämlich so beim Kunden, dass am Anfang des Sprints natürlich irgendwie 8 Einträge offen sind und die sind dann so eineinhalb Wochen offen und nach eineinhalb Wochen gehen mal 5 Einträge zu. Und wir sind ja auch genau 5 Entwickler:innen im Team drin. Ja ist ja logisch. Jeder hat halt in einem anderen Eintrag gearbeitet und dann sind wir fertig und dann fängt das große Gerödel an: Boah, wir haben noch drei, müssen wir irgendwie geschafft kriegen.

Jasmine

Dann beginnen drei Leute irgendwie einen neuen Eintrag. Zwei Leute sagen, sie haben nichts mehr zu tun und die drei Einträge werden dann auch nicht fertig. Das heißt, so Sachen kann man daran auch gut ablesen. Manchmal hilft es dann, diese Burndown Charts, egal wie man die macht, mit in die Retrospektive zu nehmen und einfach drüber zu reflektieren: was sagt das über unsere Teamarbeit aus? Sind wir gerade schon ein Team, das wirklich zusammenarbeitet oder sind wir noch eine Gruppe?

Jasmine

Verteilen wir die Arbeit auf einzelne Köpfe? Oder sagen wir: Hey, das ist das Wichtigste, was wir diesen Sprint erledigen müssen. Das heißt, wir rücken uns hier zusammen. Das heißt nicht jeder kann alles machen. Überhaupt nicht. Da muss man trotzdem ein bisschen gucken. Aber oft kann man einander aushelfen. Man kann Dinge schon mal vormachen. Irgendjemand, der langsamer ist in etwas. Aber wenn es wichtig ist, kann der jemand trotzdem anfangen.

Jasmine

Und der andere, der gerade noch mit was anderem beschäftigt ist, der schneller wäre, kommt danach hinzu. Dann haben wir auch eine gute Wissens-Verteilung. Also solche Dinge kann ich an einem Burndown Chart auch mit ablesen. Zudem dass es im Team einfach ein unglaublich guter Indikator während des Sprints gibt: Ist denn das noch zu schaffen? Wie sind wir denn gerade unterwegs?

Kai

Und wenn ich so ganz ehrlich bin, wenn ich zurückschaue, jetzt so über die 14 Jahre Scrum, wie viel Teams habe ich dabei geholfen, so ein Sprint Burndown Chart zu benutzen, egal welche Facette davon? Wenn das elektronische Werkzeug das zufällig ausgespuckt hat, dann haben wir da öfter drauf geguckt. Bei den ersten paar Teams, die ich gecoacht hab, war das auch so, dass ich die Dinger gemalt habe. So am Anfang, das irgendwann dem Team in die Hand gedrückt habe und gesagt habe malt mal selber weiter.

Kai

Und in vielen Teams ist das dann irgendwann weggefallen, weil sie den Lernpunkt verstanden hatten. Und dann war das eigentlich genug, auf das Taskboard drauf zu schauen und man sah an dem Sprint Backlog selber dann schon, wie sich die Tätigkeiten entwickeln und ob die das hinkriegen. Insofern habe ich da immer so ein bisschen gemischte Gefühle dazu. Also um ein Ziel zu erreichen im Coaching finde ich das irgendwie ganz nett und ein ganz gutes Werkzeug. Jetzt so für jedes Team bin ich so persönlich.

Kai

Also wenn das jetzt nicht so ein Jira irgrendwie ausspuckt. Zum Beispiel habe ich jetzt ein Team, das sehr gerne mit Miro arbeitet im digitalen Raum und da das Task Board drauf hat. Da gibt es natürlich so eine Visualisierung nicht und ich habe die jetzt auch nicht hinzugefügt als Coach. Auf der anderen Seite achte ich auf die ähnlichen Punkte und spreche das auch so ähnlich an. Also zum Beispiel war da das Daily oft am Anfang Personen-orientiert. Also jeder sagt mal, was er so gemacht hat und wo er dran ist.

Kai

Und ich habe das jetzt mal umgestellt auf: Lass uns mal entlang des Sprint Backlogs gehen und dann schauen wie sieht es hier aus, wie sieht es hier aus? Und dann gibt es auch so etwas wie ein kleines dann und ein kleines dann heißt so aus Sicht des Entwicklungsteams eigentlich fertig, aber dann müsste noch die Qualitätssicherung und der Product Owner guckt noch mal drauf, dann gibt es das große dann und dann, dann wird das ja auch schon mal genannt. Und das ist eigentlich ein ähnlicher Effekt, den Jasmine gerade beschrieben hat, den man auch über das Coaching mit so einem Sprint Product Burndown Chart erreichen könnte.

Jasmine

Ist ganz lustig. Ich habe da ganz andere Erfahrungen gemacht. Also die eine Erfahrung, die ich total teile, ist ja, ich benutze es als Coaching-Werkzeug und die meisten Teams, wenn sie reifer werden, brauchen das einfach nicht mehr, weil sie selber ein Gefühl dafür entwickelt haben, wenn sie auf ihr Task Board gucken. Hey, das reicht im Sprint, das reicht nicht im Sprint. Wir müssen zulegen. Da braucht niemand Unterstützung oder nicht, da reichen Teams im Coaching bei mir.

Jasmine

Ich würd über den Daumen gepeilt sagen irgendwas zwischen zwei Monaten und vier Monaten. Und dann haben wir diese Burnout Charts auch schnell mal wieder sein gelassen. Was ich zum Beispiel nie mache ist, wenn Jirar das ausspuckt drauf zu gucken. Ich find das so hässlich auf Jira, dass ich da nicht drauf gucke. Ich bin auch wirklich ein Ästhet, als ich mal das gerne selber. Ich habe das super gerne selber gemalt. Ich habe das jetzt auch mit digitalen Teams gemalt, dann war das bei mir als Kamera Hintergrund.

Jasmine

Das hat für uns ganz gut funktioniert. Wenn’s digital ist. Habe ich das oft irgendwie. Darf man niemandem sagen, nicht hingekriegt, oder ich finde es hässlich oder man muss was rumfiddeln und ich fand es anstrengend. Also beide Varianten funktionieren. Ich glaube, da wo wir die Erfahrung teilen ist irgendwann mal braucht es ein Team oft nicht mehr.

Kai

Ein anderer Korridor ist natürlich noch, wenn ein Stakeholder wissen will, wie läuft denn die Produktentwicklung generell? Und ja klar, der Product Owner oder die Product Ownerin ist da entsprechend der richtige Ansprechpartner für. Und dann ist es ja schon so, dass man so ein bisschen auch gern das Auge isst mit und was zum visuellen Kommunizieren gut brauchen kann. Und da kommen dann wieder unsere Product Burndown Charts ins Rennen und da habe ich eigentlich die gleiche Betrachtung. Nur dass ich einfach schaue.

Kai

Zum Beispiel die Anzahl aller unfertiger Product Backlog Einträge. Das können ja dann doch schon mal, weiß ich nicht. Ich sage mal bis zu 150 Stück sein. Danach finde ich, verliert man total den Überblick. Mehr sollte es nicht sein. Dann muss man eigentlich den Papierkorb aufmachen, das da reinschmeißen. Aber so bis dahin könnte man die Anzahl zählen und dann schaut man entsprechend: Wie viele sind jetzt fertig geworden, sodass man auch darunter brennt. Und da hilft es oft noch eine Linie einzuziehen, wann man ausliefern möchte.

Kai

Denn man hat ja nicht vor, das Produkt erst auszuliefern, wenn man alle 150 Einträge umgesetzt hat, sondern sozusagen die Wasserkante, auf der man da landet. Also der Meeresspiegel vom Ozean. Den kann man dann so anpassen, dass der gerade zur nächsten Auslieferung passt. Und weil es eben dieses Phänomen gibt, dass das dann so eine dynamische Linie braucht, auf der man landen möchte, dreht man das Ding auch manchmal um und da macht man Burn Up Chart, wo das entsprechend andersherum funktioniert, dass man entsprechend die Arbeit dann hoch brennt.

Jasmine

Genau. Also ich benutze Burn Up Charts in dem Zusammenhang viel, viel lieber, weil da muss ich das ganze Ding nicht ständig anpassen. Das ist mir irgendwie zu anstrengend. Ihr merkt, manchmal bin ich ein bisschen faul. Ähm, ich benutze Burn Up Charts da am liebsten und da kommt auch immer wieder die Frage: Ja, aber das muss doch jetzt genau sein. Und dann brauchen wir genaue Schätzungen und so weiter. Ein guter Freund von uns und mein Co-Speaker Joseph Pelrine sagt immer: Es ist nicht die Schätzung das Problem, sondern die politische Konsequenz der Schätzung.

Jasmine

Und so ist das auch beim Burn Up Chart. Es ist nicht das Problem, ob das jetzt genau genug ist oder nicht, sondern welche politische Konsequenz das hat. Es ist und bleibt im komplexen Raum eine Glaskugel-Rechnung. Die kann genauer werden. Aber ganz ehrlich, dann muss ich extrem viel statistisches Voodoo machen. Da ist unser Freund Joseph Pelrine, auch der, den man fragen möchte, wenn man das statistische Voodoo machen will, der ist unglaublich gut da drin.

Jasmine

Ich empfinde das ganz oft als viel zu viel Aufwand für das, was rauskommt. Das heißt einfach mal Backlog Einträge zählen und hochrechnen und gucken wie viel schaffen wir denn so im Sprint an Backlog Einträgen normalerweise. Das gibt mir schon mal eine Aussage darüber, wo wir ungefähr landen können. Dann kann ich nämlich sagen: Lieber Stakeholder, wenn die Priorisierung so bleibt, wie sie gerade im Backlog ist und wir drei Monate weiterarbeiten, dann landen wir ungefähr da und das ist ungefähr drin.

Jasmine

Und ja, es ist beides ungefähr. Aber es ist eine Aussage, die ich treffen kann und dann gehen die Geister so ein bisschen auseinander. Dann gibt es gewisse Coaches und Agilisten, die sagen: Nee, wir schätzen einfach das gesamte Backlog ein, dann werden wir genauer. Und wenn wir das gesamte Backlog eingeschätzt haben, können wir unsere Velocity nehmen. Haben wir dann auch geschätzt. Dann werden wir da auch genauer, dann können wir eine genauere Aussage treffen.

Jasmine

In meiner Erfahrung macht es keinen großen Unterschied, ob ich Backlogs Einträge zähle oder ob ich jetzt Story Points schätze und Velocity noch mit dazu nehme an Story Points oder ob ich als Velocity einfach nehme: normalerweise schaffen wir acht Backlog Einträge. Ich gehe davon aus, wir schaffen immer noch acht Backlogs Einträge. Dann kann ich auch noch eine pessimistische und eine optimistische Schätzung machen. Also viele Leute werden krank sein, was auch immer es wird jetzt Winter. Wir haben Corona.

Jasmine

Ich gehe davon aus, wir werden über die Zeit nur noch sechs Einträge schaffen. Das wäre die pessimistische Schätzung. Die optimistische Schätzung ist natürlich: Wir werden besser, weil ist ja unser Ziel, besser zu werden. Das heißt, wir werden über die Zeit elf Einträge schaffen. Dann kann ich zwei Linien ziehen und kann dann immer sagen: Im schlimmsten Fall landen wir da in drei Monaten, im besten Fall landen wir da in drei Monaten. Und dann gibt es auch ein informiertes Gespräch mit meinen Stakeholdern.

Jasmine

Wenn die sagen: Ja, aber das brauche ich unbedingt drin. Kann man sagen Ja, das ist gut. Dann lassen Sie uns auch gucken, was wir vorher rausnehmen, damit du das unbedingt drin haben kannst.

Kai

So, der Risiken und Beipackzettel, den wir noch dazulegen, ist natürlich dieses ganze Thema: schätzen und Planen ist in Scrum ja gar nicht definiert. Das ist irgendwie dazu gebastelt. Da hat Scrum jetzt per se keine Antwort drauf. Wenn ein Unternehmen gerade das Bedürfnis hat, da mehr Klarheit oder mehr Sicherheit zu haben in Bezug auf dieses komplexe Feld der Produktentwicklung. Da hat Scrum keine Antworten. Das heißt nicht, dass es in der Agilen Welt nicht, wie Jasmine beschrieben hat.

Kai

Ideen dazu gibt. Da muss man einfach einen Kontext rausfinden, was funktioniert. Und da gibt es natürlich auch ganz, ganz viele beliebte Dysfunktionen, die man kreieren kann, wenn man anfängt, zum Beispiel den Lieferanten zu bezahlen für die Anzahl der Story Points, die der umsetzt. Und solche Geschichten. Da gibt es doch einiges an Schmerzen. Da haben wir auch immer wieder Diskussionen im Seminarraum zu. Insofern muss man da ein bisschen schauen. Burndown Charts sind prinzipiell ein bisschen weggerückt von der Wichtigkeit, im aktuellen Scrum Guide ist das Wort vielleicht gerade noch vorhanden.

Kai

Ich müsste es gerade noch mal nachlesen. Aber das ist, wenn überhaupt, nur noch ein Stichwort. Früher war das mal viel präsenter da drin und mittlerweile ist das nur ein Hilfsmittel, was man neben anderen Graphen und Grafik nehmen kann, wie zum Beispiel einen kumulativen Flow Chart. Was, die Kanban-Leute  ja ganz gern benutzen, wo man dann sieht, an welcher Station der Wertschöpfung man entsprechend wie lange steht und wie lange man braucht in diesem Prozessschritt, um dann den Wert-Strom zu optimieren, was ja so die Grundidee von einem Kanban System ist

Jasmine

Für uns Quintessenz von Burn down und Burn Up Charts ist.

Jasmine

Sie helfen einem als Mittel dazu, Transparenz zu schaffen, um dann in die Kommunikation einzusteigen, sei es mit dem Team über den Sprint und das Sprint-Ziel oder mit dem Team über das Produkt-Ziel und wie sehr wir das erreichen werden, nicht erreichen werden, was wir verändern können oder auch mit den Stakeholdern. Das heißt immer dann, wenn ich das Chart oder das Hilfsmittel als das Wahrsager-Objekt nehme, wird’s schwierig, weil dann habe ich ganz viele politische Konsequenzen hintendran, da wo ich das Chart nehme als Medium dafür, Transparenz zu kreieren und dann in die Kommunikation einzusteigen, damit wir gemeinsam inspizieren und adaptieren können.

Jasmine

Da erfüllt das Tool seinen Zweck. Wir haben dir jetzt hier auch eher die Scrum Master Perspektive auf diese Charts aufgezeigt. Unsere Freunde vom Produktwerker Podcast können dir bestimmt auch noch die Product Owner Perspektive aufzeigen und was man denn da alles auch noch machen kann. Wir hauen sie an für dich.

Kai

Genau und insofern viele Grüße ins Rheinland, da komme ich ja auch ursprünglich her. Könnt ihr auch mal reinhören, wär schön. Genau. Wir freuen uns, dass du heute dir einen Überblick verschafft hast zu den Möglichkeiten des visuellen Managements, die einem dabei helfen, im Scrum Team zu arbeiten. Und wir freuen uns, wenn du ganz bald wieder einschaltet beim Agile Growth Podcast.

Jasmine

Und wie immer freuen wir uns total auf Feedback und auch so eine Sternchen Bewertung im zum Beispiel Apple-Store, damit unser Podcast noch ein bisschen größer wird, bisschen mehr Reichweite bekommt. Wenn du uns also unterstützen möchtest – wir freuen uns total auf ein paar Sternchen in dem Podcast Service deiner Wahl.

Kai

In diesem Sinne bis ganz bald wieder hier im Agile Growth Podcast.