Dieser Blog-Eintrag ist Teil einer Serie zur Detailbetrachtung von Scrum. Weitere Einträge finden Sie hier:

• Scrum Detailbetrachtung: Scrum Rollen
• Scrum Detailbetrachtung: Scrum Artefakte
• Scrum Detailbetrachtung: Scrum Meetings

Innerhalb des Scrumprozesses werden folgende unterschiedliche Scrum Kennzahlen, die einen Blick auf das Team oder den jeweiligen Projektfortschritt erlauben, definiert: Die Team Velocity, der Sprint Burndown, der Release Burndown.

Die einzelnen Kennzahlen im Detail

Die Team Velocity

Die Velocity zeigt an wie viel Arbeit ein Team innerhalb eines Sprint leisten kann. Diese Kennzahl kann dafür genutzt werden, um innerhalb der Releaseplanung die Leistungsfähigkeit und Sprintdauer für das komplette Projekt berechnen zu können (vgl. [Srinivasan], [Szalvay]).

Der Wert der Velocity berechnet sich aus den aktuell geleisteten Story Points aus den vorherigen Sprints. Diese Kennzahl verändert sich somit automatisch, sobald sich das Team verändert.

Der dargestellte Velocity-Report stellt einen automatisch generierten Team Foundation Server Report dar, der mithilfe des TFS-Projekt-Templates „Scrum for Team System“ in der Version 3 automatisch erzeugt und jederzeit abgerufen werden kann (vgl. [Scrum For Team System]).

Mit Hilfe dieser Kennzahl ist es folglich möglich folgende Fragen zu beantworten (vgl. [Bielicki]):

• Wie viel Funktionalität kann bis zur nächsten Iteration realisiert werden?
• Wie sieht der Funktionsumfang in drei Monaten aus?

Der Sprint Burndown

Der Sprint Burndown zeigt den noch zu leistenden Arbeitsaufwand für einen gesamten Sprint an. Hierfür werden auf der x-Achse die Tage des aktuellen Sprints und auf der Y-Achse der aktuelle Funktionsumfang des Sprints, typischerweise in Stunden, angezeigt.

Idealerweise erreicht der Sprint Burndown am Ende des Sprints die x-Achse (Aufwand gleich Null).

Der dargestellte Sprint Burndown stellt einen automatisch generierten Team Foundation Server Report dar, der mithilfe des TFS-Projekt-Templates „Scrum for Team System“ in der Version 3 automatisch erzeugt und jederzeit abgerufen werden kann (vgl. [Scrum For Team System]).

Mit Hilfe des Sprint Burndowns ist es möglich folgende Fragen zu beantworten (vgl. [Szalvay]):

• Wie viel Prozent der Arbeit des aktuellen Sprints wurde schon geschafft?
• Wann ist die Arbeit des aktuellen Sprints fertig, wenn das aktuelle Tempo beibehalten wird?

Der Release Burndown

Der Release Burndown zeigt vergleichbare Informationen wie ein Sprint Burndown (Restaufwand pro Tag), jedoch nicht bezogen auf einen Sprint, sondern bezogen auf das komplette Release / Product. Der Release / Product Burndown zeigt somit das Gesamtbild des Projektes, während hingegen der Sprint Burndown jeweils nur einen Auszug darstellt.

Der dargestellte Release / Product Burndown stellt einen automatisch generierten Team Foundation Server Report dar, der mithilfe des TFS-Projekt-Templates „Scrum for Team System“ in der Version 3 automatisch erzeugt und jederzeit abgerufen werden kann (vgl. [Scrum For Team System]).

Mit Hilfe des Release Burndowns ist es möglich folgende Fragen zu beantworten (vgl. [Szalvay]):

• Wie viel Prozent der Arbeit des kompletten Releases wurde schon geschafft?
• Wann ist das komplette Projekt fertig, wenn das aktuelle Tempo beibehalten wird?

In der Praxis

Die Fallen in der Scrum Metrik liegen im Detail, so werden in der Praxis häufig unterschiedliche Scrum-Teams miteinander verglichen. Hierbei erfolgt auch ein Vergleich auf Velocity-Kennzahl-Ebene. Ein Vergleich der Kennzahl, welche leider nicht Teamübergreifend eingesetzt werden kann und somit nicht vergleichbar ist. „Ohne Velocity-Vergleich lässt man der Selbstorganisation zwischen den Teams den notwendigen Freiraum. Hierbei können sich sogar einzelne Teams herauskristallisieren, die besonderen Wert auf Verbesserungsmaßnahmen im Sinne nachhaltiger Entwicklung legen und daher meist eine niedrigere Velocity erreichen – zum Vorteil der gesamten Entwicklungs-Organisation.“ (vgl. [Gutjahr])

Eine Hauptmaßnahme des Scrum Masters ist es die Leistung des Teams darzustellen. Der Transparenzgedanke durch die Veröffentlichung der unterschiedlichen Burndown-Charts macht hierbei die Team-Performance jederzeit ersichtlich und bietet somit allen Teammitgliedern eine gute Übersicht über den Projektfortschritt. Diese Charts zeigen somit jederzeit wie gut ein Team im Zeitplan liegt.

Die Erstellung der jeweiligen Kennzahlen kann hierbei entweder „per Hand“ oder automatisch über ein Tool, wie beispielsweise den Team Foundation Server von Microsoft, durchgeführt werden. Eine aktuelle Untersuchung von VersionOne (State of Agile Survey – The state of agile development) aus dem Jahre 2010 zeigt hierbei eine Übersicht über die Tools die im agilen Kontext eingesetzt werden (vgl. [VisionOne]). Generell gilt aber: Projekte werden von Menschen erledigt und nicht von Tools. Schlechte Leistungen können niemals durch gute Tools kompensiert werden, schlechte Tools aber durch herausragende Leistungen ausgeglichen werden.

Literatur

[Scrum For Team System] Scrum for Team System Guidance / Version 3 von EMC Consulting [2010]

[Bielicki] Predicting the team’s Velocity: yesterday’s weather method von Przemysław Bielicki [September 2008]

[Srinivasan] What is Velocity in a scrum team von Vibhu Srinivasan [November 2007]

[Szalvay] Glossary of Scrum Terms von Victor Szalvay [März 2007]

[Gutjahr] Team Velocity vergleichen – eine gute Idee? von Till Gutjahr [Oktober 2009]

[VisionOne] State of Agile Development Survey Results von VisionOne [2011]