Der Release Burndown Bericht zeigt dir, wie dein Team mit der Arbeit an einem Release vorankommt. In Jira Software gibt es keine Entität "Release" - eine Version ist gleichbedeutend mit einem Release (daher wird in diesem Dokument der Begriff "Version" anstelle von "Release" verwendet). Der Bericht zeigt Daten an, die auf der Schätzungsstatistik basieren, die dein Board verwendet.

Hier sind einige Möglichkeiten, wie du einen Release Burndown Bericht nutzen kannst:

• Du kannst sehen, wie schnell dein Team das Backlog abarbeitet,
• Du kannst sehen, wie sich die während des Sprints hinzugefügte und entfernte Arbeit auf den Gesamtfortschritt deines Teams ausgewirkt hat.
• Voraussagen über die Anzahl der Sprints, die du brauchst, um die Arbeit an einer Version abzuschließen, basierend auf vergangenen Sprints und Änderungen während der Sprints.

Wenn du den Versionsbericht bereits verwendet hast, wirst du einige Ähnlichkeiten feststellen. Der Release Burndown-Bericht ist jedoch für Scrum-Teams optimiert, die in Sprints arbeiten - das macht die Verfolgung viel einfacher.

1. Klicke in der Navigation auf Projekte und wähle das entsprechende Projekt aus
2. Klicke auf Berichte und wähle dann Release Burndown aus
3. Wähle die gewünschte Version aus dem Dropdown-Menü aus (Release Burndown). Du kannst aus den Versionen wählen, die in den für dein Board konfigurierten Projekten enthalten sind (über den Filter des Boards)

Um den Bericht zu drucken, rufe ihn auf und benutze die Druckfunktion deines Browsers. Der Bericht passt sowohl im Hoch- als auch im Querformat auf eine A4- oder eine Letter-Seite (es gibt einen Vorfall, der beim Drucken im Querformat mit Chrome auftritt).

Bevor du den Release Burndown Bericht verwendest, solltest du wissen, wie er funktioniert. 

Der Sprint-Balken

• Hellgrüner Bereich = abgeschlossene Arbeit während des Sprints. Wenn ein Balken komplett hellgrün ist, kannst du nicht erkennen, wie viel der abgeschlossenen Arbeit ursprünglich geschätzt wurde oder nicht. Um diese Information herauszufinden, klicke auf den Balken, um die Details zu erfahren.
• Hellblauer Bereich = Arbeit, die von der zu Beginn des Sprints geschätzten Gesamtarbeit für die Version noch übrig ist.
• Dunkelblauer Bereich = Arbeit, die während des Sprints hinzugefügt wurde, aber ursprünglich nicht enthalten war (z. B. Änderung des Umfangs).
• Hellgrüner Bereich + hellblauer Bereich = die gesamte Arbeit in der Version, die ursprünglich zu Beginn des Sprints geschätzt wurde.
• Hellblauer Bereich + dunkelblauer Bereich = die gesamte Arbeit in der Version, die am Ende des Sprints noch übrig ist.
• Balken mit grauen Bereichen = voraussichtliche Sprints (siehe unten).

Voraussichtliche Sprints

Die voraussichtlichen Sprints werden auf der Grundlage der Velocity* (der in den letzten drei Sprints abgeschlossenen Arbeit) deines Teams und der verbleibenden Arbeit in deinem Backlog berechnet. Umfangsänderungen werden bei der Berechnung der Velocity* nicht berücksichtigt, sind aber in der verbleibenden Gesamtarbeit enthalten.

*nicht mit der in der Velocity Chart beschriebenen Velocity identisch.

Betrachte folgendes Beispiel:

• Bewertung der ausstehenden Arbeit: In diesem Beispiel verbleiben 10 Story-Punkte für die Version zu Beginn des aktuellen Sprints.
• Berechnung der Velocity: In den letzten drei Sprints (Beta 5 , Beta 6 und Beta 7) wurden 28 Story Points abgeschlossen. Das ergibt eine durchschnittliche Velocity von 9 Story Points pro Sprint, wobei auf den nächsten Story Point gerundet wird.
• Vorhersage der verbleibenden Sprints: Bei einer Velocity von 9 Story Points pro Sprint werden 2 weitere Sprints (einschließlich des aktuellen Sprints) benötigt, um die Arbeit an der Version mit 10 Story Points abzuschließen. Das heißt, 1 Sprint mit 9 Story Points plus ein letzter Sprint mit 1 Story Point.

Wird mein aktueller Sprint bei der Berechnung der Velocity meines Teams berücksichtigt?

Der aktuelle Sprint wird bei der Berechnung der Velocity des Teams normalerweise nicht mitgezählt. Im obigen Beispiel zeigt der Balken für den aktuellen Sprint graue Abschnitte (wie die Balken für die vorhergesagten Sprints), um dies zu verdeutlichen. Die Ausnahme ist, wenn du im aktuellen Sprint bereits mehr Arbeit erledigt hast als vorhergesagt wurde. In diesem Fall wird der aktuelle Sprint (und die tatsächlich abgeschlossene Arbeit) als einer der drei Sprints für die Berechnung der Velocity verwendet. Außerdem zeigt der Sprintbalken grüne/blaue Abschnitte an, wie die Balken für abgeschlossene Sprints.

Wenn dein Team zum Beispiel im obigen Diagramm bereits mehr als 9 Story Points im aktuellen Sprint abgeschlossen hat, würde die Arbeit, die in Beta 6, Beta 7 und dem aktuellen Sprint (und nicht in Beta 4) abgeschlossen wurde, zur Berechnung der Velocity herangezogen werden.

Andere Funktionen

Die folgenden Fragen und Antworten beziehen sich auf die anderen wichtigen Funktionen des Release Burndown Berichts:

Warum stimmen die Daten für den ersten/letzten Sprint in meinem Bericht nicht mit dem für meine Version konfigurierten Startdatum/Release-Datum überein?

Das Startdatum und das Releasedatum, die für die Version konfiguriert wurden, werden am unteren Rand des Berichts als geplantes Startdatum und geplantes Enddatum angezeigt. Dabei handelt es sich jedoch um geplante Datumsangaben und nicht um die ersten und letzten Sprints, die im Bericht angezeigt werden.

• Der erste angezeigte Sprint ist derjenige, der den ersten Vorgang (in der Version) enthält, der den Status "Zu erledigen" verlässt, d.h. die Arbeit an der Version wird begonnen.
• Der letzte angezeigte Sprint ist der Sprint, in dem die Arbeit an der Version abgeschlossen wird; oder, wenn noch Arbeit übrig ist, der voraussichtliche Sprint, in dem die Arbeit beendet wird.

Die Zuordnung der Status zu deinem Board bestimmt, wann ein Vorgang als "Zu erledigen" oder "Fertig" gilt. Weitere Informationen findest du unter Spalten konfigurieren.

Wie wirkt sich der Prozentsatz der nicht geschätzten Vorgänge auf den Bericht aus?

Der Release Burndown-Bericht kann nur Vorhersagen treffen, die auf den geschätzten Vorgängen in deiner Version basieren. Wenn du einen hohen Prozentsatz an nicht geschätzten Vorgängen hast, sind die Vorhersagen im Bericht nicht zuverlässig (das Stichwort % nicht geschätzte Vorgänge (unestimated issues) wird rot eingefärbt, wenn der Prozentsatz über 30% liegt, um dich darauf aufmerksam zu machen).

Wenn du zum Beispiel nur 10 % der Vorgänge in der Version geschätzt hast, dann sagt der Bericht den Abschluss der Arbeit für die Version auf der Grundlage der 10 % der gesamten Vorgänge voraus. In Wirklichkeit hat dein Team wahrscheinlich noch viel mehr Arbeit zu bewältigen.

Welche Änderungen wirken sich auf die ursprüngliche Schätzung und welche auf den Umfang (zusätzliche Arbeit) aus?

Die folgenden Änderungen wirken sich auf die ursprüngliche Schätzung eines Sprints aus:

• Ein Vorgang in einer Version (bevor er begonnen wurde) wird geschätzt (Schätzung wird hinzugefügt)
• Ein Vorgang in einer Version (vor dem Start) wird neu geschätzt (Schätzung ändert sich)

Die folgenden Änderungen wirken sich auf den Umfang eines Sprints aus:

• Ein Vorgang wird zu einer Version (nachdem diese gestartet wurde) mit einer bestehenden Schätzung hinzugefügt
• Ein Vorgang, der zu einer Version hinzugefügt wurde (nachdem damit begonnen wurde), wird geschätzt (Schätzung wird hinzugefügt)
• Ein Vorgang, der zu einer Version hinzugefügt wurde (nachdem er gestartet wurde), wird neu geschätzt (die Schätzung ändert sich). Hinweis: Wenn der Vorgang in einem späteren Sprint neu geschätzt wird, wird der Umfang rückwirkend in dem Sprint angepasst, in dem der Vorgang ursprünglich hinzugefügt wurde.

Wie werden Arbeiten, die außerhalb eines Sprints abgeschlossen werden, dargestellt?

Jede Änderung (Burndown oder Umfang), die außerhalb eines Sprints stattfindet, wird als Teil des Sprints mit dem letzten Startdatum vor dem Änderungsdatum angezeigt.

Wenn ein abgeschlossener Vorgang wieder geöffnet oder zu einer Version hinzugefügt/entfernt wird, wie wird das dargestellt?

Ein Vorgang wurde in einem Sprint abgeschlossen und dann wieder geöffnet:

• Der Vorgang wird in dem früheren Sprint nicht angezeigt.

Vorgang, der in einer Version abgeschlossen, aber danach aus der Version entfernt wurde:

• Der Umfang bleibt unverändert und die abgeschlossene Arbeit wird weiterhin angezeigt.

Vorgang, der in einer anderen Version oder ohne Version abgeschlossen wurde, aber später in die Version aufgenommen wurde (auf dem Bericht angegeben):

• Der Umfang bleibt unverändert.

Vorgang, der in einem Sprint abgeschlossen wurde, aber erst danach in die Version aufgenommen wurde:

• Der Vorgang wird auf dem Bericht angezeigt, als wäre er schon immer Teil der Version gewesen.

Was ist, wenn mein Vorgang in einem nicht zugeordneten Status ist?

Wenn sich dein Vorgang in einem nicht zugeordneten Status befindet (d.h. der Status ist keiner Spalte zugeordnet), wird er im Burndown-Chart für das Release nicht berücksichtigt. Das heißt, er wird nicht in den Sprint-Balken, den % nicht geschätzter Vorgänge, den verbleibenden Story Points usw. berücksichtigt.

Wenn du auf einen Vorgang stößt, der nicht auf dieser Liste steht, melde ihn bitte auf Atlassians Issue Tracker (Englisch).