Nachdem wir erfahren haben, wie der Scrum-Prozess abläuft, geht es in diesem Teil weiter mit der Fortschrittskontrolle im Sprint. Innerhalb der Sprints erfolgt sie bei Scrum beispielsweise anhand eines Burndown Charts. Das Burndown Chart gibt Auskunft über die noch zu leistende Arbeit ab dem aktuellen Tag. Die Charts richtig lesen und anwenden zu können, ist Ziel dieses Artikels.
Auf der x-Achse werden Tage abgetragen und auf der y-Achse die Arbeit in Stunden. Jedes Teammitglied schätzt täglich den Restaufwand seiner Tasks, somit ergibt sich eine von Tag zu Tag verbesserte Genauigkeit. Hieraus können in gewissem Maße Trends und Prognosen abgeleitet werden.
Die Abbildung illustriert den im Alltag eher unrealistischen Planfall und einen eher realistischen Fall. Im Falle von »Real« hat das Team zunächst eine sehr gute Performance, besser als geplant, stellt jedoch am dritten Tag fest, dass der Aufwand für einige Tasks entscheidend höher ist.
Am vierten Tag ist das Team dennoch sehr gut vorangekommen und wieder im Plan. Ab dem fünften Tag ergeben sich höhere Aufwände als ursprünglich geplant; erst ab dem siebten Tag kann die Performance wieder verbessert werden. Durch die Erfahrung von Sprint zu Sprint kann ein Performance-Index eines Teams erstellt werden, der die Geschwindigkeit anzeigt. Dies kann u.a. über die Anzahl produktiv einsetzbarer Arbeitsstunden pro Mitarbeiter, zum Beispiel drei bis fünf von acht Stunden pro Werktag, erfolgen.
Das folgende Beispiel beschreibt ein Team, das sich zu viele Aufgaben aufgegeben hat:
Das nächste Beispiel stellt ein »Undercommitment« dar. Das bedeutet, dass einzelne Personen oder ein ganzes Team während eines Sprints nicht voll ausgelastet waren, also zu wenig Aufgaben geplant wurden. Das Burndown Chart zeigt, dass die Schätzungen der Aufgaben zum Start nicht genau genug waren.
Die Linie »Zu wenig 2« zeigt, dass es zunächst keinen Fortschritt gegeben hat und dann die Arbeit in wenigen Tagen erledigt wurde. Bis zum Durchdringen der Aufgaben war dem Team anscheinend keine gute Einschätzung möglich. Erst danach konnten die Tasks durchgänging abgearbeitet werden.
Burndown Charts liefern von Tag zu Tag genauer werdende Aussagen über Restaufwände. Diese sind sehr nah am »realen« Restaufwand, da sie aktuelle Einschätzungen des Entwicklungsteams sind. Es hilft dem Team beim Erkennen von Risiken und bei der täglichen Planung. Nicht der Projektmanager stellt den Fortschritt fest und sorgt für das Einhalten der Planung, sondern das Team selbst.
So wird deutlich, dass die gesamte Entwicklung mit dem Team steht und fällt. Eine Zeitplanung lässt sich nicht mehr gegen das Team machen, sondern nur noch mit dem Team und auf Basis des realen Fortschritts.
Doch ebenso steht bzw. fällt ein klassisch gemanagtes Entwicklungsprojekt natürlich mit denjenigen, die es realisieren. Ein nicht motiviertes oder nicht fähiges Team kann auch durch einwandfreies Projektmanagement keine Höchstleistungen erzielen. Aus dieser Perspektive heraus ist es logisch, dem Entwicklungsteam die genannten Freiheiten zu gewähren und seine Potentiale zu nutzen, anstatt sie durch starre Regeln zu gefährden.
Durch die Autonomie und die Selbstorganisation des Teams wird die Motivation des Teams auch langfristig sichergestellt. So werden nicht mehr äußere Umstände für das Entstehen von »Blockern« verantwortlich gemacht, sondern Probleme vom Team selbst angegangen und gelöst.