Gantt-Diagramme sind schlecht für die Projektplanung (/1/). Was soll denn der brave Projektmanager tun? Er braucht doch ein Werkzeug zur Planung und Kontrolle der Ergebnisse (/2/). Nicht die Hoffnung verlieren, lieber Projektmanager! Es gibt moderne Instrumente, die gut für Projekte geeignet sind: Burndown-Charts und Produkt-Checklisten. Heute nehmen wir Burndown-Charts unter die Lupe (in einigen Wochen Produkt-Checklisten).
Für die Planung, Steuerung und Berichterstattung benötigt der Projektmanager vor allem belastbare Information darüber, ob wir die geplanten Ergebnisse innerhalb des Budgets und der Zeit schaffen. Es geht deshalb um den Fertigstellungsgrad, die Arbeitsgeschwindigkeit und den Ressourcenverbrauch. Hier zeigen Burndown-Charts ihre Kraft. Typische Gantt-Charts zeigen dagegen Aktivitätendauer, Abhängigkeiten, Ressourcenabdeckung/-konflikte und Ressourcenkonsum.
Für ein gutes Burndown-Chart brauchen wir drei Kernelemente:
Das zweite Element des Burndown-Charts ist die Zuweisung von Story Points (/5/) zu jeder Karte (=Teilprodukt). Sie normalisieren die Arbeitslast der Produkte (kleiner, mittlerer, großer Aufwand). Diese Menge kann man nun als Geschwindigkeitsmesser für das Team nutzen. Auf Basis der Erfahrung, wie viele Punkte das Team in der geplanten Zeit schafft, schätzt das Team die Gesamtdauer für den Plan ab.
Das letzte Element des Burndown-Charts ist das zweidimensionale Diagramm selbst (/6/). Die x-Achse bildet die Zeit und die y-Achse die Anzahl von Story-Punkten ab. Die geschätzte Bearbeitungszeit wird von oben links (Start) nach unten rechts (geplantes Ende) als eine Linie gezeichnet. Damit zeigt der Burndown-Chart zunächst die geplante bzw. erwartete Linie der Geschwindigkeit und Fertigstellung.
Wenn die Teilprodukte fertig werden, hält der Projektmanager bzw. das Team den Bestand der tatsächlich geschafften Story Points auf dem Chart fest. So sieht man, wie schnell das Team wirklich arbeitet. Diese Linie (Ist-Linie) wird ebenfalls neben die Plan-Linie gemalt. Liegt die Ist-Linie über der Plan-Linie, bewegt sich das Team langsamer als geplant. Liegt sie unter der Plan-Linie, arbeitet das Team schneller. Der Projektmanager kann entsprechende Korrekturmaßnahmen einleiten bzw. seinem Lenkungsausschuss ehrlich Bericht erstatten.
Interessanterweise passen Burndown-Charts sehr wohl zu Gantts ursprünglichen Absichten: Er wollte die echte Produktivität eines Teams messen, damit Manager rechtzeitig reagieren können. Gantt erkannte, dass die Leistungsniveaus von einzelnen Personen oder Teams variieren. Diese Tatsache sollte entsprechend akzeptiert und realistisch bei der Planung berücksichtigt werden (und nicht durch unrealistisches Wunschdenken, Schuldzuweisungen oder Druck bekämpft werden). Wenn der Plan unrealistisch erscheint, ist laut Gantt eindeutig der Manager schuld.
Warum eignen sich Burndown-Charts dann besser für Projekte als Gantt-Charts, wie wir sie von typischen Planungstools wie MS Project kennen?
Für die Planung, Steuerung und Berichterstattung benötigt der Projektmanager vor allem belastbare Information darüber, ob wir die geplanten Ergebnisse innerhalb des Budgets und der Zeit schaffen. Es geht deshalb um den Fertigstellungsgrad, die Arbeitsgeschwindigkeit und den Ressourcenverbrauch. Hier zeigen Burndown-Charts ihre Kraft. Typische Gantt-Charts zeigen dagegen Aktivitätendauer, Abhängigkeiten, Ressourcenabdeckung/-konflikte und Ressourcenkonsum.
Für ein gutes Burndown-Chart brauchen wir drei Kernelemente:
- ein Kanban-Board,
- geschätzte Story Points und
- das Burndown-Chart (/3/) selbst.
- Backlog,
- Work in Progress,
- Done
Das zweite Element des Burndown-Charts ist die Zuweisung von Story Points (/5/) zu jeder Karte (=Teilprodukt). Sie normalisieren die Arbeitslast der Produkte (kleiner, mittlerer, großer Aufwand). Diese Menge kann man nun als Geschwindigkeitsmesser für das Team nutzen. Auf Basis der Erfahrung, wie viele Punkte das Team in der geplanten Zeit schafft, schätzt das Team die Gesamtdauer für den Plan ab.
Das letzte Element des Burndown-Charts ist das zweidimensionale Diagramm selbst (/6/). Die x-Achse bildet die Zeit und die y-Achse die Anzahl von Story-Punkten ab. Die geschätzte Bearbeitungszeit wird von oben links (Start) nach unten rechts (geplantes Ende) als eine Linie gezeichnet. Damit zeigt der Burndown-Chart zunächst die geplante bzw. erwartete Linie der Geschwindigkeit und Fertigstellung.
 |
| Abb. 1: Burndown Chart (Beispiel) |
Wenn die Teilprodukte fertig werden, hält der Projektmanager bzw. das Team den Bestand der tatsächlich geschafften Story Points auf dem Chart fest. So sieht man, wie schnell das Team wirklich arbeitet. Diese Linie (Ist-Linie) wird ebenfalls neben die Plan-Linie gemalt. Liegt die Ist-Linie über der Plan-Linie, bewegt sich das Team langsamer als geplant. Liegt sie unter der Plan-Linie, arbeitet das Team schneller. Der Projektmanager kann entsprechende Korrekturmaßnahmen einleiten bzw. seinem Lenkungsausschuss ehrlich Bericht erstatten.
Interessanterweise passen Burndown-Charts sehr wohl zu Gantts ursprünglichen Absichten: Er wollte die echte Produktivität eines Teams messen, damit Manager rechtzeitig reagieren können. Gantt erkannte, dass die Leistungsniveaus von einzelnen Personen oder Teams variieren. Diese Tatsache sollte entsprechend akzeptiert und realistisch bei der Planung berücksichtigt werden (und nicht durch unrealistisches Wunschdenken, Schuldzuweisungen oder Druck bekämpft werden). Wenn der Plan unrealistisch erscheint, ist laut Gantt eindeutig der Manager schuld.
Warum eignen sich Burndown-Charts dann besser für Projekte als Gantt-Charts, wie wir sie von typischen Planungstools wie MS Project kennen?
- Sie halten den Fokus auf den Ergebnissen. Story Points normieren den Aufwand.
- Es wird nur das kontrolliert, was wichtig ist: Ergebnisse (Qualität), Geschwindigkeit und Ressourcenverbrauch. Das ist alles, was den Lenkungsausschuss interessiert.
- Aktivitätenkontrolle mit einem Gantt-Chart liefert i. d. R. ein falsches Bild. Wie Pareto gezeigt hat, gibt es keine für die Projektsteuerung brauchbare Korrelation zwischen verbrauchter Zeit und Ergebnis (außer bei einfachen Tätigkeiten).
- Die Kontrolle von Aktivitäten bedeutet die Kontrolle von Menschen. Diese Kontrolle ist im besten Fall unnötig und im schlimmsten Fall schädlich für die Arbeitskultur. Wir sollten von einem Menschenbild des verantwortungsvollen Erwachsenen ausgehen, der zum Selbstmanagement fähig ist. Damit steigt sowohl die Leistungsqualität als auch die Zufriedenheit mit der Arbeit.
- Burndown Charts motivieren. Die Verschiebung eines Teilprodukts in "Done" ist ein Erfolgserlebnis, das motiviert, selbst wenn die Ist-Linie noch über der Planlinie liegt.
Anmerkungen
- /1/ James Lee: Gantt-Diagramme sind toll, nur nicht für Projekte, Teamworkblog, erschienen am 14. Januar 2013, abrufbar unter http://www.teamworkblog.de/2013/01/gantt-diagramme-sind-toll-nur-nicht-fur.html
- /2/ Wallace Clark and Henry Gantt: The Gantt chart, a working tool of management. New York, Ronald Press, 1922, abrufbar unter http://archive.org/details/ganttchartworkin00claruoft. Mr. Gantt hat seine Charts nicht für Projekte sondern für die Betriebsplanung genutzt, insbesondere, um die Auslastung von Menschen und Maschinen zu optimieren.
- /3/ Die Idee des Burndown Charts stammt anscheinend aus der agilen Produktentwicklung, wobei es Hinweise darauf gibt, dass sie viel älter sein könnten. Jeff Sutherland - einer der "Erfinder" von Scrum - war Bomberpilot. Wie er auf Burndown-Charts kam, gibt dieses Interview wieder: http://labs.openviewpartners.com/videos/an-overview-of-the-burndown-chart-and-its-history/. Burndown Charts sind mit Earned Value Analysis verwandt. Das ist eine Methode, die es noch schwerer mach, aktivitätenorientiert zu denken. Siehe: http://alistair.cockburn.us/Earned-value+and+burn+charts
- /4/ Mehr Informationen zu Kanban gibt es bei der Wikipedia und hier im Teamworkblog.
- /5/ Gregg Boer beschreibt in einem Artikel im Visual Studio Magazine Story Points ganz gut. (siehe Gregg Boer: Unleash the Power of Story Points, Artikel im Visual Studio Magazine, erschienen am 07. November 2012, abrufbar unter http://visualstudiomagazine.com/articles/2012/11/07/story-points-in-agile-development.aspx). Es gibt eine Diskussion darüber, ob man Zeitaufwand an Stelle von Story Points verwenden kann (siehe http://www.industriallogic.com/blog/stop-using-story-points/). Allerdings ist dieser Ansatz ist umstritten (siehe http://scrum.jeffsutherland.com/2009/04/sprint-burndown-by-hours-or-by-story.html).
- /6/ Joel Wenzel: Burn Down Chart Tutorial: Simple Agile Task Tracking, erschienen bei joel in point form am 13. November 2010, abrufbar unter http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
Kommentare
Kommentar veröffentlichen