The Product Backlog – where does it come from?

The Product Owner has often been considered a bottleneck when creating a Product Backlog, as he was deciding which items would be included. Nowadays, new practices have been introduced to ensure that the Product Backlog is defined more efficiently.
Curious to find out how it’s done? Join me in my how-to video!

Video: Product Backlog II

Nachdem ich im letzten Video gezeigt habe, wie das initiale Product Backlog eines Teams entsteht, erkläre ich euch in diesem Video den Prozess für das Aufbauen eines Backlogs – nämlich so, dass tatsächlich die Bedürfnisse eurer User erfüllt werden. Auch das ist keine Raketenwissenschaft, sondern die Anwendung einfachster Techniken, um zu schnellen Ergebnissen zu kommen.
Ihr werdet Elemente des Design Thinkings finden und dann ist es euch überlassen, vom prototypischen Entwickeln hin zum fertigen Produkt zu gelangen.
Viel Spaß beim Anschauen — Boris
 

Video: Product Backlog I

Woher kommt eigentlich das Product Backlog? “Na vom Product Owner”, sagen viele. Meine Erfahrung ist, dass dieser Ansatz nicht sehr gut funktioniert.
Es gibt eine viel geschicktere Lösung, um das erste Product Backlog aufzustellen. Wie das geht, zeige ich euch in diesem kleinen Video.
Viel Spaß beim Anschauen — Boris
 

Reporting built in!

In allen Unternehmen, bei denen ich bereits eine Scrum-Implementierung begleiten durfte, war das Thema Reporting immer ein schwieriges und kontrovers diskutiertes. Meistens sind der Hintergrund die Statusreports aus dem klassischen Projektmanagement mit einer Ampel, Ergebnissen, Aktivitäten, Risiken und Handlungsbedarf – in mehr oder weniger abgewandelter Form. Vielleicht fehlt mir ein bestimmtes Gen, aber ich konnte aus diesen Statusreports noch nie relevante Infos rausziehen.
Was man sich ansieht und was bei den Report-Lesern hängen bleibt, ist die Ampel. In der Regel steht sie auf Grün – höchstens mal Gelb – niemals jedoch würde man sich die Blöße geben, dass man auf Hilfe von außen angewiesen ist. Die Personen, die diesen Report erstellen müssen, halten ihn in der Regel für überflüssig und nicht aussagekräftig. Schreibt man etwas Unerwünschtes hinein, muss man sich mit Nachfragen rumquälen, die  jedoch nur davon abhalten, das Problem zu lösen – denn Unterstützung und Hilfe sind eher ein Ausnahmefall.
Und dann kommt plötzlich Scrum. Die POs müssen erst die neuen Artefakte kennen- und nutzen lernen. Das Management und sonstige Reporting-Anforderer sind aber in der Regel etwas schneller als dieser Gewöhnungsprozess. Sie hatten ja vorher einen Status-Report und auf einmal haben sie nichts – oder vielleicht ein paar Zettel. Also fängt man an, sich Gedanken zu machen: Wie könnte ein Reporting in Scrum aussehen?

Oft vergisst man dabei, dass das Reporting in Scrum eigentlich “Built in” ist! Pflegt der Product Owner die ureigenen Artefakte wie den Releaseplan kontinuierlich und wird ein Burndownchart für das aktuelle Release geführt, sollten alle relevanten Informationen vorliegen und sogar aussagefähiger sein als jede Prosa. Diese Artefakte zeigen genau, was tatsächlich bereits geliefert wurde und was in Zukunft geplant ist. Eine Erklärung, warum das so ist, ist natürlich in keinem der beiden Reporting-Vorgehen ausgeschlossen.
Was muss der Kunde oder das Management über diese Form des Reportings wissen? Wie ein PO auf einem meiner Projekte so schön anmerkte: “Es wird viel zu oft in vorauseilendem Gehorsam etwas erstellt, das für den Kunden vielleicht zu viel, zu wenig oder in anderer Art und Weise unzureichend ist. Wir müssen erstmal verstehen, was der tatsächliche Bedarf ist!” Daher:

Welche Erfahrungen habt ihr gemacht? Was braucht euer Kunde? Wie integriert ihr das in den Prozess bzw. nutzt es gleichzeitig als Reporting für das Team?

Mut zur Wahrheit: Der erste Releaseplan

Nicht vieles ist so schön wie das Gefühl, einen Plan zu haben. Das gilt sowohl für das Privatleben – beispielsweise für den lang ersehnten Urlaub – als auch für den Beruf, speziell in der Projektwelt. Doch was passiert, wenn der sorgsam geschmiedete Plan nicht den Hauch einer Chance auf eine halbwegs vernünftige Umsetzung hat? Das Hotelzimmer liegt nicht wie angekündigt direkt am Meer, sondern man schaut in den dunklen Innenhof, wo Bauarbeiter seit 7 Uhr mit einem Presslufthammer den Boden rausreißen und außerdem ist dem jüngsten Spross speiübel, die Tauchausflüge sind also gestrichen.
Beim Lieblingsprojekt des Vorstandes verhält sich das nicht anders: Werdende Mütter und Väter, die den Großteil des Entwicklungs-Know-hows auf sich vereinen, nehmen Elternzeit, noch bevor sie es geschafft haben, wenigstens einen Teil ihres Wissens mit den Kollegen zu teilen. Der nächstbeste Mitarbeiter wurde von der alljährlichen Grippewelle ereilt und natürlich kommt auch noch ein gesetzliches Muss-Thema reingeflattert, womit die restlichen Reserven fast vollends aufgebraucht wären. Und, hat damit jemand gerechnet, als man das Projekt vor etwas mehr als einem Jahr auf „naja, sagen wir mal 2000 Personentage“ geschätzt hat? In den meisten Fällen leider nicht. Die Leidtragenden sind in solchen Fällen meist die Übriggebliebenen, die nun die gleiche Arbeit mit der Hälfte der Ressourcen erledigen müssen – der Termin steht ja schließlich schon seit einer halben Ewigkeit fest, Verzögerungen werden mit Argwohn quittiert.
Doch wie kann man hier Abhilfe schaffen? Ist das Projekt zeitlich bereits so weit fortgeschritten wie oben beschrieben, bleibt den Teams nicht sehr viel mehr, als mit den gesammelten Informationen für Transparenz bezüglich der tatsächlich leistbaren Arbeit herzustellen und entweder auf Verständnis zu hoffen, oder eben zusätzliche Ressourcen zur Verfügung gestellt zu bekommen.
Diese Transparenz lässt sich besonders einfach mit Hilfe eines Releaseplans realisieren. Hierbei werden sämtliche User Stories der vergangenen Monate nach Bearbeitungszeit sortiert (diese lassen sich in elektronischen Tools wie JIRA relativ einfach bestimmen). Am Ende erhält man sowohl die kürzeste, als auch die längste Durchlaufzeit für eine User Story und kann mit großer Wahrscheinlichkeit sagen, dass keine der noch offenen User Stories länger dauern wird, als die bisher auf „done“ gesetzten Stories. Da man außerdem eine durchschnittliche Velocity pro Sprint erhält, kann man nun auch eine Aussage darüber treffen, wie viele Sprints das Entwicklungsteam für die noch offenen und bereits geschätzten Stories noch benötigen wird.
Da hier in der Regel eine deutliche Diskrepanz zwischen Planung und Realität zu Tage tritt, hat ein solcher Releaseplan erfahrungsgemäß mindestens zwei Konsequenzen: Er sorgt für eine noch deutlichere Priorisierung der offenen Projekte und User Stories. Und zweitens tritt der ebenfalls erwünschte Effekt ein, dass die Scrum Teams nun häufiger und früher in die Planung einbezogen werden, um böse Überraschungen zukünftig zu vermeiden.
Der Releaseplan ist also ein einfaches und wirkungsvolles Tool, um auf der Basis bisher gesammelter Erfahrungen und tatsächlich gemessener Velocity relativ valide Aussagen darüber treffen zu können, auf welcher Stufe sich mein Produkt gerade befindet. Probieren Sie es aus!

Das Review als Nicht-Meeting

Der Sprint ist zu Ende. Das Team legt die Arbeit nieder und geht in das Review. Und schon ist sie wieder da: Die steife Meeting-Atmosphäre, in der die erlegten Stories nacheinander vorgeführt werden, ScrumMaster und Product Owner im Mittelpunkt stehen, und Anwesende ungeduldig auf den Stühlen rutschen. Wenn es ganz schlecht läuft, muss das Team sich auch noch gegenüber Product Owner und Management rechtfertigen, warum etwas so und nicht anders umgesetzt wurde.
Ein gutes Review ist wie eine gute Retrospektive: In dem einen geht es um die Auseinandersetzung mit dem Prozess, in dem anderen um die Auseinandersetzung mit dem Produkt. Alles andere sollte im Review im Hintergrund verschwinden. So ist es für das Review zum Beispiel irrelevant, wie viele Stories das Team geschafft hat. Ebensowenig sollte das Team im Review irgend etwas vorführen müssen, das keinen Nutzer interessiert. Deshalb macht der Product Owner die Abnahme der fertigen Stories bereits im Sprint und nicht erst im Review.
Für ein erfolgreiches, spannendes und wirklich kommunikatives Review kommt es auf die richtige Perspektive an:

Wie gestaltet ihr Eure Reviews? Was hat funktioniert, was nicht?

Sie können abschalten, wir haben die Vision

Was sagt die Hirnforschung zum Nutzen von (Produkt-)Visionen? Ich bin daran höchst interessiert, aber ich weiß es nicht. Was ich allerdings weiß, ist Folgendes:
In der Hirnforschung gibt es einen Bereich, der sich mit Improvisation beschäftigt. Improvisation ist ein kreativer Prozess, Jazz ist dafür ein gutes Beispiel. Wir wissen, dieser Musikstil lebt von Improvisation. Misst man die Gehirnaktivität bei der Improvisation, dann stellt man etwas Spannendes fest: Entgegen der ersten Annahme, dass ein Feuerwerk der Aktivität im Hirn veranstaltet wird, schaltet das Hirn bestimmte Teile stark ab. Klar sind die Teile des Hirns, die für das Hören zuständig sind, sehr aktiv. Aber der frontale Teil des Hirns  (Frontallappen) schaltet sich bewusst weitgehend ab. Genauer gesagt schaltet sich der planerische Teil des Hirns ab – also der Teil, der weiß, was als Nächstes getan wird, der den Schritt nach dem Schritt kennt. Aktiv bleibt allerdings der Teil, der sich den langfristigen Zielen oder Rahmen widmet. Im Jazz wären das dann die kulturellen Grenzen der jeweiligen Zeit (Zeitgeist) und die damit verbundenen Muster.

Zu welcher Schlussfolgerung bringt mich das?

Wenn wir davon ausgehen müssen, dass wir für kreatives Handeln wie bspw. Improvisation sowohl 1.) einen Rahmen zur Orientierung brauchen und wenn 2.) kreative Prozesse planerisches Handeln ausschalten, dann bringt mich das zu Folgendem:
Planen und kreatives Handeln stehen für unser Hirn im Konflikt. Immer wenn wir Neues erschaffen, benötigen wir einen Rahmen, eine Orientierung, eine Marschrichtung, eine langfristig angelegte Mission oder Vision. An dieser Vision richten wir uns aus und im Rahmen der Orientierung können wir kreativ handeln. Den zu genauen Plan schiebt unser Hirn beiseite (sobald wir etwas Neues erschaffen müssen). Der Plan im Vorfeld ist nicht wichtig und kann nicht beachtet werden. Ausgehend von einem sehr groben Zielbild, einer Vision, die als Rahmen dient, orientiert sich unser Hirn an langfristigen Zielen. Diese Ziele müssen bekannt sein und grob vorliegen. In der Agilität schaffen wir eine Vision, arbeiten mit User Stories und in Scrum mit Sprint Goals. Alle drei Artefakte folgen dem groben Rahmen und vermeiden das detailreiche Planen. Könnte unser Hirn die Grundlage für den Erfolg dieser Artefakte sein?
Ob ich damit richtig liege, ich weiß es nicht. Ist es wichtig? Ich denke, nein. Wichtig ist jedoch zu wissen, dass Kreativität viel mit Kontrolle des Hirns über das Abschalten von Hirnaktivität zu tun hat und dass zuviel Detailplanung in kreativen Prozessen teilweise nicht berücksichtigt wird und unnötig ist – zumindest dann, wenn wir einen erneuten kreativen Prozess starten. Vielleicht noch ein belehrender Hinweis zum Schluss: Immer wenn wir neue Anforderungen für unser Produkt angehen, immer dann, wenn wir Software in Schale gießen, dann starten wir einen solchen kreativen Prozess.
Bevor Sie jetzt abschalten, noch eine Frage: “Wie ordnen sich meine obigen Gedanken zu ‘Front-Up-Design’ und zu ‘Emergent-Design’ ein?”

Definition of Done: Die harte Schule

Das Ende des Sprints naht und nur noch Tasks wie “Systemdoku ergänzen” und “Abnahme mit dem PO durchführen” kleben in der To-Do-Spalte. Ein Blick auf die Definition of Done neben dem Board verrät, dass das Team sich dazu committed hat, die Doku abzuschließen, bevor sie eine Story als DONE deklariert und somit dem PO zur Abnahme übergeben kann.
Nun ist es aber doch dringend, man könne die Systemdoku doch auch machen, nachdem die Abnahme vom PO erfolgt sei. Sie wäre ja schließlich sowieso nur von Entwicklern für Entwickler, den PO würde das nicht interessieren und er würde es auch nicht lesen. Vielleicht würde er noch Fehler finden oder Anpassungen haben wollen und dann müsse man die doch dringender machen als die Systemdoku. Ein Implementierungs-Task sei schließlich wichtiger als ein Doku Task …

Die Biegbarkeit der DoD

Ich diskutierte lange mit dem Teammitglied über Sinn und Unsinn der DoD. Als dann das Argument fiel “Dann müssen wir eben die DoD anpassen, da steht sowieso zu viel drin! Und du hast gesagt, dass das Team die DoD festlegt, stimmts?”, mischte sich ein weiteres Teammitglied ein. Zuerst stimmte er in den Chor der DoD-Kürzung ein, doch bei ernsthafter Betrachtung stellte er fest: “Naja, der faule Entwicklerteil in mir sagt, dass wir etwas streichen sollten, aber der vernünftige sagt, dass wir es sonst nur wieder aufschieben. Dann wird es so wie in den alten Projekten: Die Doku machen wir, wenn wir noch Aufwand übrig haben! Und dann hat man natürlich keinen Aufwand übrig!”
Im Nachgang, als ich von dem Erlebnis erzählte, wurde mir klar, dass Scrum wahrscheinlich einfach eine Methode ist, mit der sich Menschen selbst überlisten. In einem guten Moment schreibt man alles auf, was sinnvoll ist und committet sich schnell dazu, bevor man es sich wieder anders überlegt. Später fragt man sich an der einen oder anderen Stelle, warum genau man sich auf so etwas eingelassen hat. Hätte man nicht gleich sehen können, wie unrealistisch das ist bzw. wie viel Disziplin nötig ist, um das dauerhaft einzuhalten? Immerhin würden mir heute tausend Gründe einfallen, warum etwas anderes viiieel wichtiger ist als Doku, nochmaliges komplettes Testen nach einer minimalen Änderung, Testautomatisierung etc.
Pilotprojekten wird oft ein großer Vertrauensvorschuss gewährt. Man hebelt die “normalen” Prozesse aus und vertraut, dass das Team mit seinem eigenen Anspruch eine hohe Qualität liefert. Das ist gut und richtig. Oft jedoch holen einen alte Verhaltensweisen wie Featuredruck oder das Ziel der Performance-Steigerung schnell ein. Die Teammitglieder sind gewohnt an der Qualität zu sparen, wenn es knapp wird, kurzfristige vermeintliche Erfolge über z.B. die Wartbarkeit zu stellen. Im Einzelfall scheint es daher manchmal kleinkariert, auf den Regeln zu beharren. In dieser Situation sollte man sich schleunigst daran erinnern, dass man sich aus gutem Grunde selbst ausgetrickst hat.

Wie schreibe ich eine User Story oder anders gefragt: Was nützt mir der Nebel?

Der Weg zur User Story fällt vielen erstmal schwer und zwar an der Stelle, an der man es eigentlich nicht erwarten sollte: Beim Formulieren des Nutzens. Wir sind so darauf getrimmt Funktionen zu beschreiben, dass uns der Nutzen implizit bewusst ist, jedoch anfangs nicht zu greifen erscheint. Einen Nutzen zu beschreiben und ihn in Worte zu fassen fällt schwer, es ist wie das Greifen nach einem Nebelfaden, der kurz vor der Berührung zerstäubt.
Im Nebel, so fühlen sich viele Teams, wenn sie Anforderungen ohne Nutzen übergeben bekommen. Sie müssen anfangen die Schemen, die geschrieben stehen, zu interpretieren. Den Nutzen in den Sätzen, Zusammenhängen zu finden, die Schwaden zu durchtrennen und zu entwirren. Gelingt es, dann haben wir bestenfalls eine Funktion mit einer Interpretation des Nutzens und wir können hoffen, dass die Beteiligten miteinander reden, um zu validieren, ob die Funktion auch den gewünschten Nutzen erfüllt.

“Gib mir einen Nutzen und ich gebe dir die Funktion dazu, die Du dir wünscht.”

Das ist mein persönlicher Leitspruch und auch meine Empfehlung, wenn es darum geht, User Stories zu schreiben. Fangt mit den Fragen “Wer” und “Wozu” an und schreibt diese auf. Startet beispielsweise so:
Als Stammkunde Ralf Müller möchte ich …, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Wenn ihr eine gute Idee habt, dann schreibt noch die Frage nach dem “Was” dazu, also die Funktion:
Als Stammkunde Ralf Müller möchte ich eine Benachrichtigung, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Am besten ist es, wenn ihr das “Was” gemeinsam mit eurem Entwicklungsteam klärt. Verstehen sie den Nutzen, dann werden Sie eine Funktion finden, die den Nutzen erfüllt. Spätestens im Sprint Planning 1 sollten die Anforderungen dann geklärt werden. Vielleicht schlägt das Entwicklungsteam neben der E-Mail Benachrichtigung und der direkten Anzeige auf der Folgeseite noch das Versenden einer Benachrichtigung per Blumenstrauß vor – wer weiß.
Um der angesprochenen Funktion etwas mehr Gestalt zu geben, formuliert ihr noch Akzeptanzkritierien. Dadurch könnt ihr den Rahmen aufspannen und vorgeben, was minimal erfüllt werden muss – nicht mehr, aber auch nicht weniger. Auch diese Kriterien klärt ihr gemeinsam mit dem Entwicklungsteam und zwar im Dialog und zwar von Angesicht zu Angesicht. Vom Entwicklungsteam lasst ihr dann Akzeptanztests bzgl. der  Akzeptanzkritierien aufstellen. Ein Kriterium könnte in unserem Beispiel sein:
Die Bestätigung erfolgt auf zwei Kommunikationskanälen. Ein Kommunikationskanal ist im System, der andere der Postweg.

Warum sollte das Entwicklungsteam die Funktion ausformulieren?

Das ist für mich implizit eine Frage nach der Reife des Teams. Jedes Entwicklungsteam lernt am eigenen Produkt die Fachdomäne, in der es sich bewegt und wird über die Zeit zum Domänenspezialisten. Das ist jedoch nur ein Grund, ein wichtigerer ist der folgende: Jedes Team weiß am besten, wie sich der gewünschte Nutzen im System am besten abbilden lässt. Ein cross-funktionales Team zeigt hier seine Stärken, jedoch kennt jedes andere Entwicklungsteam es auch besser als der Kunde bzw. die meisten User. Man fragt sie nur zu selten.
Ein Grund hierfür ist sicherlich, dass die User sich nicht die Fragen stellen müssen, die ein Teammitglied sich stellt, zum Beispiel: “Wie passt die Funktion in das Konzept der Anwendung?”, “Muss ich hier auch die Funktionen A, B und C berücksichtigen?” Ein Entwicklungsteam hat einen ganz anderen Kontext zum Produkt, das es entwickelt. Dieser muss aufgebaut werden.

Was benötigt eine gute User Story jetzt noch?

Wir haben das normale Format mit Wer, Was, Wozu – also: Als <Persona> möchte ich <Funktion>, damit ich <Nutzen>. Wir haben Akzeptanzkritierien , die aufzeigen, was minimal geliefert werden muss. Akzeptanztests, die das Entwicklungsteam ausformuliert und die aufzeigen, dass die Akzeptanzkritierien erfüllt werden. Was fehlt?
Es ist der Nebel.
In unserem Beispiel ist der Nebel zuerst der leere Funktionsteil. Hier muss Kommunikation erfolgen, damit geklärt wird was selbst der Platzhalter Benachrichtigung später konkret heißen soll. Konkret gesagt ist der Nebel keine Worthülse, die beliebig interpretiert werden darf, trotzdem ist der Nebel die Unklarheit auf dem Weg zur Implementierung.
Eine User Story ist ein Anlass zur Konversation. Das bedeutet, wir benötigen eine gewisse Unstabilität in der User Story, damit eine Konversation, ein Dialog entstehen kann. Wir brauchen Unschärfe. Hier brauchen wir allerdings die Art von Nebel, die nicht verschleiert. Nicht der Nebel, der durch schöne Worte und vermeintliche Vollständigkeit und die stumpfe Präzision eines Löffels uns denken lässt: “Alles steht hier geschrieben, genau das brauchen wir so wie es formuliert wurde.” Nein, wir brauchen den Nebel, der uns fragen lässt: “Hey, sollen wir lieber links oder rechts gehen, ich bin mir gerade nicht ganz sicher.” Software-Entwicklung ist zu großen Teilen ein Kommunikationsproblem und zu genaue Anweisungen verstärken dieses Problem. Bei zu genauen Anweisungen fragen wir nicht mehr nach, die Kommunikation versiegt.
Für viele von Euch ist die Fahrt, der Spaziergang im Nebel erstmals ungewohnt, lasst ihn trotzdem zu und lasst Euch drauf ein. Es ist faszinierend, was nach kurzer Zeit vor einem auftaucht und welche Überraschungen und Details einem ins Auge fallen, die man aus der Ferne, selbst mit Weitblick, nicht hätte erkennen können.

Das Burndown-Chart – 10 Gründe dafür

Das Burndown-Chart dient in Scrum dem Reporting, aber das ist lange nicht alles. Einzelne Elemente in Scrum verstärken sich gegenseitig und das Burndown-Chart ist eines davon. Hier 10 Punkte, warum das Burndown-Chart den Scrum-Flow bereichert:

  1. Es zeigt die Leistung eines Teams innerhalb eines Sprints. D. h. es zeigt an, wie viel Funktionalität bereits fertiggestellt und lieferfähig ist.
  2. Es hilft dem Team, den inneren Schweinehund zu überwinden, indem das Team täglich angespornt wird, die Funktion fertigzustellen. Es setzt täglich einen Reflektionspunkt für das Team und fördert den Fokus auf das zu Liefernde.
  3. Es verstärkt das Anreizsystem der Lieferung, da nur fertiggestellte Funktionen gemessen und dadurch belohnt werden.
  4. Es dient der Transparenz gegenüber dem Management. Das Management kann jederzeit ablesen, ob und wie viel ein Team liefern wird.
  5. Es bringt Teams dazu, offen mit der eigenen Arbeit umzugehen. Hier dient es als wichtiges Startsignal, um Offenheit im Unternehmen zu fördern. Wer transparent mit seinem Arbeitsfortschritt umgeht, der fördert auch die Kooperationsbereitschaft zwischen Teams und Abteilungen.
  6. Es zeigt an, dass ein Team unter Last steht und nicht gestört werden darf. Dabei hilft es vor allem, den Sprint stabil zu halten und keine Ad-Hoc-Anforderungen mit aufzunehmen.
  7. Es zeigt auf, wenn an zu vielen Dingen parallel gearbeitet wird.
  8. Es lässt das Team den eigenen Erfolg feiern. Täglich einmal auf dem Burndown-Chart nach unten oder ab unter die Solllinie – einfach ein tolles Gefühl.
  9. Es dient als Diagnosemittel, bspw. zeigt es Verzug auf. Wenn es hakt, dann sieht man es hier. Das Burndown-Chart bringt Verzug symptomatisch ans Licht, egal ob es an Impediments liegt, das Team parallel an mehreren Geschichten gleichzeitig arbeitet oder gar etwas komplett anderes macht.
  10. Es zeigt auf, wenn Stories zu groß geschnitten sind. Eine weitere Ursache, die das Burndown-Chart zu Tage fördert, sind überdimensionierte User Stories. Ist eine Story zu groß, so erkennt man das auch an der Flatline auf dem Burndown-Chart.

Das Burndown-Chart lässt sich auch sehr gut in Retrospektiven und Reviews einsetzen. Hier dient es als Anstoß für Diskussionen. Nutzt das Burndown-Chart dafür, euren Blick kurz aus dem Tagesgeschäfts zu heben, durchzuatmen und euren Blick auf das Produkt und die versprochene Lieferung schweifen zu lassen. In diesem Sinne: Burn it down baby!