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

Der Version Report – eine Alternative zum Projektburndown

JIRA bietet neben Burndown Graph und Velocity Chart noch weitere Reports an. Einer davon: der Version Report – was kann der und wozu ist er gut?

version report schaubild agile board jira

So sieht ein einfacher Version Report in JIRA aus. Auf der Y-Achse die Story Points, auf der X-Achse die Zeit.

Wie sieht ein Version Report aus?

An der X-Achse steht die Zeit, an der Y-Achse die Story Points. Das kommt einem gleich bekannt vor, denn es handelt sich um die gleichen Merkmale, die auch das Burndown Chart verwendet. Beide Schaubilder verwenden das Verhältnis der Gesamtsumme der Story Points zur Summe der erreichten resp. noch offenen Story Points um eine Aussage über den Projektfortschritt zu treffen. Der Unterschied liegt – wie eben angedeutet (erreichte vs. noch offene Story Points) – in der Perspektive der beiden Charts. Dabei gibt es beim Version Report nicht nur eine Trendgerade, sondern einen Zielkorridor, mit drei Zielterminen – einem optimistischen, einem realistischen und einem pessimistischen Zieltermin. Näheres dazu gibt es in der Atlassian Dokumentation (s.u.).

Zur Erinnerung: die Perspektive eines Burndown Graph

Das Burndown Chart stellt die noch offenen Story Points ins Verhältnis mit der Zeit (die im Sprint oder im Projekt noch bleibt). Das heißt, das Burndown illustriert wo wir, bei linearem Fortschritt über die verstrichene Zeit, sein müssten und wo wir derzeit sind. Der Fokus liegt also auf dem gegenwärtigen Zeitpunkt. Es geht darum sich an der Ideallinie zu orientieren und ein Situationsbewusstsein zu entwickeln. Daraus lässt sich selbstverständlich auch ein Ausblick bzw. eine Erwartung über den weiteren Verlauf ableiten. Das Hauptaugenmerk liegt jedoch auf dem Jetzt und auf der Beantwortung der Frage: „Wie steht’s um den Fortschritt?“

Da der Graph die Restaufwände in Form von Story Points abbildet, die über den zeitlichen Verlauf (hoffentlich!) abnehmen, startet die Kurve im Schaubild oben links und bewegt sich nach rechts unten. Daher auch der Name – Burndown Graph.

Blickwinkel eines Version Report

Der Version Report setzt grundsätzlich auf die gleichen Daten wie auch der Burndown Graph. Und doch gibt es eine Besonderheit: Der Version Report stellt neben der Zeit die bereits erreichten Story Points dar, setzt also das erreichte mit der Zeit ins Verhältnis (zur Erinnerung: beim Burndown war es das noch offene das in Relation zur Zeit gesetzt wird).

Daraus leitet sich auch die Richtung des Schaubilds ab: Es fängt unten links an und wächst nach oben rechts.

Die Aussage eines Version Report

Der Version Report sagt mir wie schnell und in welchen Schritten das Team wie viele Story Points (und dahinter stecken wiederum Features) erfolgreich abschließt. Und es sagt mir ab einem bestimmten Zeitpunkt – wenn nämlich genug Daten für eine Prognose vorliegen – wie lange das Team voraussichtlich für alle Story Points brauchen wird.

Ändere ich den Scope sehe ich sofort die Auswirkungen auf den Zieltermin. Wenn ich spät dran bin sehe ich wie viele Story Points wohl nicht erreicht werden können – eine wichtige Information wenn es bspw. darum geht Verzögerungen in konkrete Features zu übersetzen die nicht erreicht werden. Auch umgekehrt wird ein Schuh draus: wieviel Luft ist noch bis zum Endtermin?

Der Report sagt jedoch nichts darüber aus, wie sinnvoll die bearbeiteten Stories sind – das muss im Planning über die Priorisierung sicher gestellt werden.

Bleibt die blaue Fortschrittskurve flach, sollte ich – wie beim Burndown auch – einen genaueren Blick auf das Projekt werfen. Gibt es Blocker? Oder handelt es sich einfach um (über-)große Stories? Wenn ja, kann ich sie splitten um die Übersichtlichkeit zu erhöhen? Und so weiter…

Vorteile gegenüber dem Burndown

Das Burndown und der Version Report sind sich also recht ähnlich. Beide nutzen (fast) die gleichen Größen um das Schaubild zu zeichnen. Zeit – klar. Und die Aufwände, nur in unterschiedlicher Form (da aus unterschiedlicher Perspektive): zum einen wieviel Aufwand noch übrig ist, zum anderen wieviel Aufwand abgearbeitet wurde.

Und da liegt meines Erachtens der Vorteil des Version Report gegenüber dem Burndown: Der Version Report ist robuster – und das aus zwei Gründen: er schaut auf die Haben-Seite – es werden ausschließlich Aufwände (hier: Story Points) summiert, die erfolgreich abgeschlossen sind. Folglich interessiert er sich nicht dafür wieviel noch offen ist, kommt also auch durch Scope Changes nicht ins Trudeln.

Ich weiß welcher Wert bereits geschaffen wurde: Was haben wir bisher erreicht? Und ich weiß gleichzeitig auch welche Erwartungen ich an den weiteren Fortgang des Projekts richten kann: Wie weit kommen wir noch in der verbleibenden Zeit?

Ein Beispiel um das zu verdeutlichen: Was passiert wenn ich bei einem Burndown den Scope erweitere? Die Kurve geht nach oben (genauer: die Steigung der Kurve wird verfälscht, sie fällt nicht in dem Maße in dem Aufwand abgearbeitet wurden, sondern steigt mitunter sogar). Dabei handelt es sich jedoch nicht um einen Fehler – das Burndown ist weiterhin korrekt. Klingt komisch, ist aber so. Das Burndown zeigt weiterhin den Gesamttrend an, jedoch ist es in solchen Situationen nicht immer einfach zu lesen und führt dadurch zu Verwirrung.

Was passiert nun wenn ich in einem Version Report Scope hinzufüge? Oder etwas genauer gefragt: was passiert mit der Kurve im Version Report wenn ich den Scope erweitere? Die Antwort: Nichts. Die Kurve bleibt wie sie ist. Denn sie zeigt das was bisher erreicht wurde und das Verhältnis zur Basis (die X-Achse) bleibt gleich. Lediglich die Obergrenze des Schaubilds wird verschoben und damit der projizierte Schnittpunkt der Kurve (erfolgreich abgeschlossene Storypoints) mit dieser Obergrenze. Dadurch ist das Schaubild zum einen leichter zu lesen – die Velocity / der Fortschritt wird immer unmaskiert, also nicht durch Scope Changes verfälscht, dargestellt.

Scope als Steuerungsinstrument

Zum anderen gibt es dem PO die Möglichkeit mit dem Scope zu steuern. Bin ich schneller unterwegs und habe zum Endtermin noch Luft, kann ich den Scope erweitern:

Version Report Schaubild Scope kann noch erweitert werden

Zum Endtermin von 27 habe ich die Stories die sich in der fix version befinden abgeschlossen und hätte sogar noch Luft – Zeit mir zu überlegen ob ich noch Features nachziehe …

Hier habe ich bis zum Endtermin noch Luft, ich kann also Features in den Scope ziehen. Und zwar in einem Umfang von maximal b (im Schaubild die größere der beiden roten, eckigen Klammern). Stories im Umfang von a (die kleinere der beiten Klammern) sollten jedoch in jedem Fall rein passen. Das ist wieder der oben erwähnte Zielkorridor mit optimistischem / realistischem / pessimistischen Zieltermin.

Und natürlich auch umgekehrt. Geht mir die Zeit aus, kann ich den Scope reduzieren und sehen was ich zum Endtermin voraussichtlich fertiggestellt haben werde:

Version Report aus JIRA - Scope sollte reduziert werden

Hier sollte ich darüber nachdenken den Scope zu reduzieren, also Stories aus der fix version zu entfernen, denn zum Endtermin bei 17 werde ich nicht alles abgeschlossen haben.

Zum Endtermin wird’s leider nichts mit dem kompletten Scope. Ich sollte hier nun reduzieren. Mindestens um a, um sicher zu gehen sollte ich mich evt. auf ein Volumen von b vorbereiten.

Feature cut?! Erzähl mir was neues!

Gut, dass man bei fixem Termin am Scope dreht ist nicht neu – das ist aber auch nicht der Punkt. Entscheidend ist, dass ich als PO im Version Report sofort die Auswirkungen prognostiziert bekomme. Auf Basis der genauen Velocity des Teams und das noch ohne die Fortschrittsmessung zu verfälschen:

ein Version Report vor und nach dem Feature Cut

So sieht ein Version Report in JIRAs Agile Board aus, wenn man den Scope reduziert.

Man sieht deutlich wie der Scope reduziert wurde – die schwarze Gerade rechts von „today“ sitzt wesentlich niedriger. Dabei bleibt der Teil links von „today“, also was bisher passiert ist, stabil. Und ich kann sofort den neuen Zieltermin ablesen (der Einfachheit halber ist hier kein Zielkorridor eingezeichnet, den gäbe es in JIRA aber).

Ja, man kann auch im Burndown die gesamte Kurve nach oben verschieben und vermeidet dadurch diese Maskierung. Dazu muss man jedoch alle Werte / Messpunkte aktualisieren – und da wird’s dann mitunter aufwändig und fehleranfällig.

Der Version Report ist da die bequeme Alternative.

Wo gibt es diesen Report und was muss ich dafür tun?

Während des letzten Projekts habe ich den Version Report parallel mitlaufen lassen um zu lernen wie sich das Schaubild in welchen Situationen verhält. Dazu habe ich den Burndown Graph und den Version Report nebeneinander gehalten – ich weiß was im Projekt los ist, wie dann das Burndown aussieht und habe gesehen wie sich das im Version Report darstellt. Und ich habe darauf geachtet was gegeben sein muss damit der Report funktioniert:

  1. Die Stories müssen (zumindest grob) geschätzt sein – eigentlich klar. Dafür eignet sich der Sprint 0 übrigens hervorragend.
  2. Die Stories müssen einer fix version im JIRA zugeordnet sein. Dabei ist es wichtig, dass die fix version nur entfernt wird, wenn die Story aus dem Scope fliegt. Wenn die Story mit einem anderen Release ausgerollt wird einfach eine zweite fix version anlegen und im Issue eintragen.
  3. Tipp: die fix version für den Version Report am Tag des Projektstarts erstellen – ich verwende hier den ersten Tag des ersten Umsetzungssprints (also nicht Sprint 0). Zwar kann man im JIRA, dort im Plan-View des Agile Board, den Startzeitpunkt der Version angeben, jedoch nicht nachträglich anpassen. Der Version Report im Agile Board läuft ab dem Zeitpunkt zu dem die fix version in JIRA angelegt wurde – das ist auch der Startpunkt für die Projektionsgerade. Legt man die fix version zu früh an, dann ist die Trendgerade viel zu flach – been there, done that. Zum Glück nur beim Testen und nicht im Produktivbetrieb.

Sind die Stories also angelegt, geschätzt und steht Sprint 1 an, dann wie gesagt die fix version anlegen und alle Stories die zum Projektscope gehören da eintragen. Das geht im Agile Board übrigens sehr einfach: alle Stories markieren und per drag & drop auf die fix version, links am Bildrand, muss man zunächst aufklappen, werfen.

Ab dem Zeitpunkt steht der Version Report im „Report“ Tab des Agile Board zur Verfügung. Dabei gibt’s aber folgendes zu beachten: die Prognose – also wann die fix version vollständig umgesetzt sein wird – gibt’s erst, wenn 10% aller Story Points erfolgreich abgeschlossen sind. Finde ich verständlich – schließlich braucht man zunächst mal eine Datenbasis um die Velocity zu ermitteln. Und wenn ich ehrlich bin: 10% ist schon gut, niedriger geht seriös nicht.

Wir sind inzwischen vom Projektburndown auf den Version Report umgestiegen. Und es funktioniert gut.

Hier noch ein paar Links:

Verwandte Artikel

Schönen Sonntag!