Überwachung des Sprint-Fortschritts & fokussierte Arbeit im Sprint: Der Einsatz vom Burn Down Chart

Überwachung des Sprint-Fortschritts

In Scrum übernimmt das Entwicklungsteam ein hohes Maß an Verantwortung. Es muss sich dementsprechend aufstellen und lernen, mit Unsicherheiten im Sprint umzugehen und zu arbeiten. Die meisten Teams sind es nicht gewohnt, diese neue Art der Verantwortung zu übernehmen und erkennen die  Notwendigkeit, im Sprint nachzusteuern, viel zu spät. Dies kann leicht schlafende Hunde wecken und “alte Micromanager” reaktivieren, dem Team diese Verantwortung abzusprechen. Häufig erfolgt aus dieser neuen Team-Verantwortung und der damit einhergehenden Skepsis, dass Burn Down Charts als Überwachungstools des Managements genutzt werden und nicht für den eigentlichen Zweck, für den sie bestimmt sind: Ein Hilfsmittel, als Team zusammenzuarbeiten und fokussiert Ergebnisse hervorzubringen. In Podcast #11 “Überwachung des Sprint-Fortschritts & fokussierte Arbeit im Sprint” gehe ich genau auf diese Problematik ein und erkläre die Funktion von Burn Down Charts, wofür sie gedacht sind und wie sie dem Team im Sprint helfen, Ownership zu übernehmen.

Was ein Burn Down Chart nicht ist.

 

Vor Scrum war es In vielen Organisationen üblich, dass nicht die Teammitglieder die Arbeit im Blick haben und nach steuern, sondern das Management oder die Leitung eines Teams/eines Projekts. Entsprechend häufig wird daher die Arbeit mit Tools wie dem Burn Down Chart falsch gedeutet und zweckentfremdet … 

  • für das Reporting aus der Arbeit im Sprint
  • als Datengrundlage für die Überwachung der Arbeit im Sprint durch das Management
  • für den PO, der sich ebenfalls verantwortlich fühlt für das, was im Sprint passiert

Genau für diese Zwecke ist ein Burn Down Chart nicht gedacht. Es geht bei der Überwachung des Sprint-Fortschritts nicht darum, das Team zu kontrollieren, sondern vielmehr darum, ein Hilfsmittel zu bieten, welches das Team unterstützt, seine Arbeit unter Kontrolle zu haben und Verantwortung zu übernehmen.

Scrum schreibt nicht vor, wie wir den Sprint-Fortschritt überwachen. Die Erwartung ist nur, dass ein Entwicklungsteam Ownership übernimmt und weiß, wo es mit seiner Arbeit steht und wo es nachsteuern muss. Dafür kann auch die Erweiterung des Sprint Backlogs zu einem Task Board ausreichen. In der Praxis werden Burn Down Charts sehr häufig genutzt, um den Sprint Fortschritt zu überwachen, da sie die relevanten Informationen verdichten und prägnant veranschaulichen.

Wofür Burn Down Charts wirklich gedacht sind: Vom Team fürs Team

 

Burn Down Charts sind dafür gedacht, dem Team einen Überblick und die Kontrolle über die  Arbeit im Sprint zu geben. Um dies zu erreichen, braucht es ein Entwicklungsteam, das die Verantwortung für den Sprint übernimmt und frühzeitig in der Lage ist, im Sprint nachzusteuern. Es muss proaktiv handeln und zeigen, dass  es seine Arbeit unter Kontrolle hat, vertrauenswürdig ist und bei Bedarf die Umwelt über Veränderungen informiert. Bei Bedarf bedeutet allerdings nicht, einfach nur auf Grundlager der aufgezeigten Linie im Burn Down Chart zu agieren, sondern vielmehr auf Grundlage der Rückschlüsse, die das Team (und nur das Team) aus dem Burn Down Chart zieht. Genau um dieses proaktive Handeln zu unterstützen, bildet das Burn Down Chart zwei unterschiedliche Dimensionen anhand zweier Achsen ab: Die Zeit im Sprint und die offene Arbeit im Sprint.

 

In diesem Chart wird der aktuelle Fortschritt im Sprint festgehalten. Um Probleme deutlicher erkennbar zu machn, beinhalten Burn Down Charts immer auch eine Ideallinie. Die Ideallinie bewirkt, dass Teams sich kritisch mit dem Fortschritt im Sprint auseinandersetzen – vor allem dann, wenn der Fertigstellungsgrad über der Ideallinie liegt und das Team erkennt, dass es mit der Arbeit (verglichen mit der Ideallinie) zurückliegt. Genauso ist ein Wert unter der Ideallinie ein Indikator dafür, potentiell noch Luft im Sprint zu haben.

 

Wichtig ist dabei, dass eine kritische Auseinandersetzung mit den Informationen erfolgt, die ein Burn Down Chart liefert. Das Chart sollte als eine Art Einladung für ein Gespräch genutzt werden, denn die Daten sprechen nicht zwangsweise für sich selbst. Das Team verfügt über das notwendige Wissen zum Kontext und kann so die Daten dementsprechend deuten. Eine isolierte Betrachtung ist nicht ratsam, denn selbst wenn das Burn Down Chart “schlecht” aussieht, kann ein Team dennoch alles im Griff haben. Umgekehrt kann ein Team, selbst wenn das Burn Down Chart “gut” aussieht, den Sprint aus irgendeinem Grund nicht schaffen. Es geht darum, die aktuelle Lage zu kennen und darüber zu sprechen. 

Offene Arbeit im Burn Down Chart: Tasks oder Backlog Items? 

 

Im Burn-Down Chart kann man unterschiedliche Einheiten nutzen, um die offene Arbeit darzustellen. 

Gern werden Burn Down Charts auf Basis von Tasks geführt. Meiner Meinung nach weist diese Art der Darstellung gewisse Schwachpunkte auf. Ich werde sie im Folgenden dennoch aufzeigen und im Kontrast dazu meine präferierte Einheit, die Darstellung der Arbeit anhand von Backlog Items, erläutern.  

1. Burn Down Chart auf Basis von Tasks

 

Im Sprint Planning können Backlog Items in Tasks heruntergebrochen werden (mehr Informationen zum Task Board und den Tasks findest hier), Diese Tasks können entweder auf Basis ihrer Anzahl oder anhand der Summe der geschätzten Stunden als Startzustand im Burn Down Chart eingetragen werden.

 

Das Team aktualisiert das Chart während des Sprints kontinuierlich und visualisiert auf der Zeitlinie die noch vorliegende Anzahl an offenen Task. Dies kann entweder täglich manuell (beispielsweise im Daily) oder über automatische Updates mithilfe eines Tools erfolgen. Die daraus entstandene Übersicht kann beispielsweise im Sprint Planning als Indikator genutzt werden um zu erkennen, ob ein Team nachsteuern muss.

 

Die bereits erwähnte Dysfunktion resultiert aus der Granularität und dem hohen Detailgrad der einzelnen Tasks.

 Nutzen wir Tasks zur Darstellung unseres Sprint-Fortschritts, kann es passieren, dass das Burn Down Chart positiver dargestellt wird, als die Situation tatsächlich ist. Dadurch, dass wir eine detaillierte Darstellung unseres Backlogs betrachten, kann es vorkommen, dass einfache Tätigkeiten zuerst gewählt werden und schwierige Tasks lange liegen bleiben. Das Resultat ist, dass das Team  viel zu spät im Sprint darauf eingeht, worauf es ankommt und dadurch sehr schlecht nachsteuern kann. Darüber hinaus wird diese Darstellung zum Problem, wenn wir einzelne Tasks vergessen. Dies ist aufgrund des hohen Detailgrades der Darstellung und der anspruchsvollen Arbeiten, die wir mit Scrum angehen, völlig normal. Die Notwendigkeit, Items zu ergänzen wird allerdings erst im Verlauf des Sprints klarer und führt daher gegen Ende des Sprints zu einem Anstieg an Tasks. 

Die Fokussierung auf einfache Tasks am Anfang des Sprints in Kombination mit dem nachträglichen Hinzufügen von vergessenen Tasks führt dazu, dass kurz vor Ende des Sprints die Anzahl an Tasks steigt und die Komplexität der Items zusätzlich sehr hoch ist.  Das Team erkennt zu spät, dass es sich übernommen hat. Das Resultat ist ein überfüllter Sprint. Aus diesen Gründen empfehle ich lieber einen Burn Down Chart auf Basis von Backlog Items zu erstellen.

2. Burn Down Chart auf Basis von Backlog Items

 

Bei der Darstellung der Arbeit durch Backlog Items wird verbleibende Arbeit anhand von Backlog Backlog Items im Burn Down Chart ein eingetragen. Es handelt sich hierbei in den meisten Fällen um User Stories. Diese können einfach nach ihrer Anzahl aufsummiert oder in relativer Schätzung zueinander dargestellt werden. Jedes mal, wenn ein Backlog Item zu 100% abgeschlossen ist, fällt die Linie im Chart entsprechend.

 

Warum diese Variante meine präferierte Darstellung ist, lässt sich einfach verdeutlichen: Diese Variante des Burn Down Chart ist pessimistischer, da die “Linie” sich erst mit einem abgeschlossen zu 100 % abgeschlossenen Item verringert. Dadurch schafft sie den richtigen Fokus für das Team. Ein Vorarbeiten mit einfachen Tätigkeiten gibt uns keinen Scheinvorteil mehr.

Das Burn Down Chart wird hier zu einem Indikator, der sehr früh Probleme aufzeigt, auf die wir dementsprechend eingehen können. Darüber hinaus fördert diese Darstellung eine neue Arbeitsweise: Um nah an der Ideallinie arbeiten können, benötigen Teams einen Austausch. Integriert man dieses Chart beispielsweise in einer guten Art und Weise als Trigger für ein Gespräch in das Daily, kann es genau der Anstoß sein, früh gegenzusteuern um erfolgreich mit Scrum zu arbeiten.

Scrum bedarf einer neuen Arbeitsweise

 

Steigt man auf Scrum um,  muss man sich immer wieder bewusst werden über die Andersartigkeit dieser Arbeitsweise. Waren wir es vorher gewohnt,  alleine vor uns hinzuarbeiten, so ist es das Ziel mit Scrum, in extrem enger Zusammenarbeit mit unterschiedlichen Expertisen ein Ergebnis zu produzieren, und weg von der scheinbar effizienten Arbeitsweise unterschiedlicher Disziplinen zu kommen. 

 

Am Anfang ist auch die Nutzung eines Burn Down Charts ungewohnt. In den allermeisten Fällen verläuft die Linie flach, weil wir uns schwer tun, im Sprint etwas abzuschließen. Der Grund dafür ist, dass jeder versucht, an “seinem” Item alleine und entsprechend seiner Profession nachzugehen. Was sich oft gut anfühlt, ist in der effektiven Arbeit mit Scrum nicht hilfreich. Wir weichen uns aus.  Wenn jeder seinem eigenen Thema nachgeht, lebt das Team sich auseinander. Dies widerstrebt jedoch der Grundintention von Scrum, denn die Idee war es, eine enge Zusammenarbeit als Team zu ermöglichen um schnell zu liefern und über Grenzen hinweg gemeinsam die Synergien zwischen den Disziplinen zu nutzen.

 

Erfolgreiche Entwicklungsteams arbeiten also im Vergleich zu früher (vor Scrum) anders und sind dadurch effektiver. Und das ist auch gut so, denn: Wenn nichts anders wäre, könnten man auch kaum andere Ergebnisse erwarten. Man kann sogar behaupten, dass Scrum bei einer Ansammlung von Individuen, die ihre Arbeit isoliert bestreiten, kaum noch Sinn macht. Im Gegenteil:  Es entsteht Unmut darüber, “ständig” Meetings abhalten zu müssen, die beim Abarbeiten stören. Ein unausweichliches Resultat, wenn man eine teamorientierte Methode ohne echte Teamarbeit einsetzt. 

Enge Zusammenarbeit im Team fördern

 

Es gibt verschiedene Wege, wie wir eine enge Zusammenarbeit im Team fördern können. Ich möchte hier einige Ideen vorstellen, wie ich das angehe.   

  • Das Daily kann um die Frage “Was fehlt?” ergänzt werden, um das nächste Item abzuschließen
  • Es kann in der Planung darauf eingegangen werden, wie wir das erstes Item früh abschließen können
  • Es kann hilfreich sein, das erste Item gemeinsam anzugehen und eine Belohnung für die Fertigstellung für den kommenden Tag ausloben
  • Es macht Sinn, das Thema Zusammenarbeit in der Retro anhand folgender Fragestellungen ans Team aufzugreifen
    • Wie können wir in engerer Zusammenarbeit schneller Items abschließen?
    • Welche Skills müssen besser verteilt werden?
    • Was an unserer Arbeitsweise hält uns zurück?
  • Die Teamarbeit wird gefördert, wenn Burn Down Charts auf Basis von Backlog Items benutzt werden 

Eine enge Zusammenarbeit im Team verbessert letztendlich nicht nur das Burn Down Chart, sondern es schafft auch einen anderen Spirit und eine Dynamik, Ergebnisse zu erzielen. Das Team arbeitet dadurch effizienter, managed Risiken besser und es hat mehr Spaß bei der Arbeit.   

Zusammenfassung

Das Sprint Monitoring wird oft für die Befriedigung des Informationsbedürfnisse der alten Arbeitsweise benutzt und erzeugt dadurch Dysfunktionen. Es ist eigentlich ein Trigger, um im Team zu arbeiten und sich auszutauschen – auch wenn es ungewohnt ist. Alternativ zum Burn Down Chart kann auch ein  Task Board dafür genutzt werden. Ein Burn Down Chart bleibt stellt allerdings ein deutlich konkreterer Anstoß für ein Gespräch dar. Burn Down Charts basierend auf Tasks sind oft zu optimistisch und erzeugen Dysfunktionen. Burn Down Charts auf Basis von Backlog Items sind weniger optimistisch. Sie forcieren den Austausch und zudem, dass das Team seine Arbeit umstellt und eng zusammenarbeitet. 

Übrigens: Solltest Du interessiert sein, dich im Rahmen eines Trainings noch einmal genauer mit den Scrum Events, Artefakten und Rollen theoretisch sowie praktisch auseinanderzusetzen, empfehle ich das Certified Scrum Master Training

 

Schreibe einen Kommentar