Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

Messungen und Reports – Voraussetzung für „inspect and adapt“

Daten sind eine abstrakte Sache. Und doch sind sie für uns im täglichen (Arbeits-)Leben – im operativen Geschäft wenn man so will – wichtig. Das liegt daran dass „messen“ heißt bestimmten Sachverhalten bestimmte Werte zuzuweisen. Daten – diese abstrakten Dinger – erlauben also grundsätzlich einen Rückschluss auf die Wirklichkeit. Da tut es besonders weh, wenn Mitmenschen die Möglichkeiten und Grenzen selbst von einfachsten Darstellungsformen nicht (er-)kennen. Ein kleiner Grundkurs.

Dabei halte ich mich – der Einfachheit und der Themenverwandtschaft wegen – an Charts und Diagramme die entweder typisch für Scrum / agile Methoden sind bzw. die man im JIRA standardmäßig bekommt. Das werden zunächst das Velocity-Chart und das Burndown-Chart sein. Von letzterem gibt es ein paar Ausprägungen auf die ich später näher eingehen möchte. Zunächst zum Velocity-Chart und dazu was es sagt und was es eben nicht sagt.

Das Velocity-Chart

Das Velocity-Chart mit geplanten und tatsächlich abgelieferten Storypoints für vier Sprints.

Das Velocity-Chart mit geplanten und tatsächlich abgelieferten Storypoints für vier Sprints.

Das Velocity-Chart – ein guter Bekannter, der im Gewand eines Balkendiagramms – oder, wie oben zu sehen als gruppiertes Balkendiagramm – daherkommt. Bei JIRA kriegt man eben das gruppierte Balkendiagramm zu sehen – hier Schwarz dargestellt die Summe aller in den Sprint eingeplanten Storypoints, in Blau die Summe der Storypoints aller abgeschlossenen Stories. Ziemlich einfach, oder?!

Was sagt es aus?

Nun, es macht die Sprints miteinander vergleichbar: Wieviel wurde in diesem Sprint abgeschlossen? Ist es mehr oder weniger als im Sprint davor? Da es sich um Storypoints handelt erlaubt das Chart (in gewissem Umfang) den Rückschluss ob viel / wenig Funktionalität fertiggestellt wurde. Bitte beachten: die absolute Zahl selbst sagt erstmal gar nichts aus. Erst im Vergleich zu den vorangegangenen Sprints wird ein Schuh draus – Werden wir schneller? Wurden wir irgendwo gebremst? Das sind Ausgangspunkte um weitere Fragen zu stellen und im Falle des Falles Ursachenforschung zu betreiben.

Was sagt es nicht aus?

Das Chart sagt nichts darüber aus ob die geleistete Arbeit auf das Projekt einzahlt. Das muss im Planning sichergestellt werden. Das Chart sagt auch nichts darüber was die Gründe für eine hohe oder niedrige Velocity in einem Sprint waren. Den Kausalzusammenhang muss man schon selbst herstellen – das Ding nimmt einem das Denken nicht ab.

Auch noch wichtig: das Chart ist kein 100%iger Beweis ob ein Sprint gut oder schlecht war. Bspw. ist denkbar dass in diesem Sprint nur 10 Storypoints (davor 20) abgeschlossen wurden. Was aber wenn diese Storypoints mit einem Viertel der Kapazitäten erreicht wurden?

Fazit

Das Velocity-Chart ist ein Indikator, ein Anhaltspunkt. Wenn die Velocity plötzlich runter geht, sollte man einen Blick drauf werfen – vielleicht ist die Sache harmlos (bspw. Urlaub vieler Teammitglieder), vielleicht steckt aber auch ein Problem dahinter.

Ich finde es auch gut einem Team eine Hilfe bei der Selbsteinschätzung zu geben. Waren wir in dem Sprint besser (lies: schneller) als im vorangeganenen? Eine realistische Selbsteinschätzung ist wichtig um im Zweifel Maßnahmen einzuleiten – inspect and adapt.

Am Ende jeder Sprintreview / Retrospektive schaue ich mir mit meinen Teams neben dem Burndown auch das Velocity-Chart an – einen Ausdruck hänge ich immer ans Taskboard. Probiert’s mal aus, es hilft ein Situationsbewusstsein zu entwickeln. Ohne ist Blindflug.

Verwandte Artikel

Schönen Sonntag!