Wir nutzen TFS und die Projektvorlage ScrumForTeamSystem. Unser Taskboard für die Daily Scrums ist also digital. Wir treffen uns täglich rund um einen 24" Monitor und schieben unsere digitalen Aufgabenzettel übers Taskboard. Die Burndown Charts des Sprints wird daraus automatich ermittelt.
Neulich hatte ich mit einem Kollegen, der Scrum nicht kennt, eine interessante Diskussion. Der Anstoß der Diskussion war ein Blick auf unser aktuelles und vergangene Burndown Charts.
Die Fragestellung: "Warum weicht den Euer Fortschritt in den Burndown Charts so stark vom Plan ab?" und "Warum plant ihr die Sprints nicht so, dass die Ist-Kurve auf der Plan-Kurve liegt?"
Oben sind drei Beispiele von Burndown Charts aufgezeigt. Stellt die rote Kurve eine falsche Planung dar? "Vertrödelt" das Team gar die Zeit und bringt nichts fertig?
Was würde es denn bedeuten ein Team exakt auf die grüne Kurve hin zu trimmen? Wir Entwickler würden in in unseren Aufwandsabschätzungen dazu einfach genügend Puffer einbauen. Wir wollen dann ja auch ganz sicher gehen, dass wir im Zeitraster der Plankurve bleiben. Nun kann sein, dass sie diesen Puffer benötigen. Wahrscheinlicher ist es aber, dass sie ihn nicht benötigen. Dies bedeutet, dass in einer grünen Kurve eine Menge Zeitreserven stecken. In einer Roten aber keine.
Fazit: Allzu glatte Burndown Charts können nur mit genügend Zeitreserven erreicht werden.
0 Kommentare:
Kommentar veröffentlichen