tl;dr
Ein Gantt-Chart aus Scrum-Daten verschafft mehr Überblick als ein Release-Burndown. Dazu erweitert man das Backlog um Kalenderspalten, in denen jeweils der Sprint markiert ist, in dem eine Story bearbeitet wird. Nebeneffekt: Management bekommt eine Roadmap und weiß was das Team macht. Steigert die Akzeptanz bei Gantt-verwöhnten Stakeholdern.
Was
Das Gantt-Chart stammt aus der klassischen Projektplanung bei der sehr detailliert Aufgaben, Abhängigkeiten, Termine und Ressourcen verwaltet werden. Droht ein Termin zu platzen, dann bekommt die gefährdete Aufgabe mehr Ressourcen.
Das ist nicht die Sichtweise von agiler Entwicklung. Bei Scrum wird nicht von vorne herein das gesamte Projekt im Detail durchgeplant ist. Es wird nur geplant wird, was auch umgesetzt wird. Teams und nicht Ressourcen übernehmen Aufgaben. Eher wird der Scope reduziert oder ein Termin verschoben, als Ressourcen (die ja Menschen sind) umher zuschieben.
Mit der klassischen Detailplanung kann man ganz genau sagen, wie ein Projekt laufen wird, zumindest wie es laufen soll. Die Wahrheit stellt sich hinterher heraus. Und sie ist immer anders als geplant. Mit anderen Worten: die genaue Projektplanung führt nur dazu, dass man sich genau irrt. Ein Grund warum die klassische Projektplanung im Agile-Umfeld verpönt ist. Damit ist auch das Gantt-Chat, als Übersicht des klassischen Projektplans, in Misskredit geraten.
Warum
Dabei hat es das nicht verdient. Auch bei Scrum wollen Stakeholder wissen, wann was fertig wird. Scrum will die genaue Aussage darüber vermeiden. Aber trotzdem bleibt der Wunsch nach konkreten Aussagen. Das Interesse von Management und Kunden am Projektfortschritt ist berechtigt und kann mit einer Roadmap im Gantt Stil befriedigt werden. Nicht zuletzt hilft eine Roadmap-artige Übersicht auch dem überzeugten Scrum-Befürworter, rechtzeitig Scope und Termine zu steuern.
Überraschenderweise hält der Scrum-Standard alles bereit, um ein Gantt-Chart zu erstellen. Ein Gantt-Chart, das alle Anforderungen von Gantt-Chart-verwöhnten Stakeholdern erfüllt. Die Erzeugung des Gantt-Charts kann automatisiert werden. Sie kostet im Scrum Prozess nichts. Das Ergebnis ist auch nicht genauer als die bekannten Gantt-Charts klassischer Projektplanung. Aber es dient der Transparenz. Damit erfüllt es eine wichtige Funktion im Scrum. Gleichzeitig fördert das Gantt-Chart die Akzeptanz von Scrum durch wichtige Stakeholder (Management).
Hier geht es also um ein Gantt-Chart als Reporting-Tool, nicht als Planungstool. Die Planung ist komplett Scrum.
Wie
Ein Gantt-Chart aus Scrum-Daten zu erstellen ist sehr einfach. Jede geschätzte Scrum User Story hat Story Points. Die Story Points entstehen ganz normal wie bisher im Scrum Prozess. Aus vorangegangenen Sprints ist die Velocity (Story Points pro Sprint) bekannt. Die bisherige Velocity wird auch für die Zukunft angenommen.
Dann berechnet man für jede Story in welchem Sprint sie fertig wird und markiert den Sprint im Kalender. Done.
Daraus ergibt sich ein Backlog mit zusätzlichen Kalenderspalten in denen jeweils die Felder markiert sind in denen eine Story in Arbeit ist und/oder fertig wird. Das sieht dann so aus:
Bonus
Zusätzliche Ideen aus der Praxis:
- Abgeschlossene, "in Arbeit" und zukünftige Stories farblich unterscheiden.
- Zukünftige Velocity = letzte Velocity modifiziert durch Sondereffekte wie Urlaub.
- Ein zusätzliches Datumsfeld je Story, das angibt für wann ein Feature dem Kunden/Management "versprochen" wurde (Soll-Datum). Das Datum wird im Kalender markiert. Soll/Plan/Ist-Angaben helfen der Transparenz.
- Epic Stories weiter unten im Backlog können auch mal über mehrere Sprints gehen.
- Zusätzlich zur Scrum-Beschreibung der Story (Wer, Was, Warum) kann man einen kurzer Titel/Namen der Story vergeben. Das hilft der Übersichtlichkeit im Gantt-Chart.
- Bewährt hat sich eine eigene Hintergrundfarbe für Releases. Das sind oft Gruppen von Stories, die aus einem Epic hervorgegangen sind. Damit kann man Stories zu "Releases" oder "Milestones" gruppieren.
_happy_charting()
