Jiras Version Workload Report wird eingestellt – der Nachbau in Report Builder in 5 Minuten
Atlassian stellt Jiras eingebauten Version Workload Report ein — und ein Ersatz „würde eine zusätzliche Lösung erfordern“, so Atlassian selbst. Community-Antworten empfehlen Näherungen über gespeicherte Filter und Statistik-Gadgets, doch keine davon reproduziert die Kernansicht des Berichts: verbleibende Arbeit in einem Release, aufgeschlüsselt nach Person und Vorgangstyp.
In Report Builder ist das eine Konfiguration von fünf Minuten, ganz ohne Template.
Was der Version Workload Report gezeigt hat
Für eine gewählte Fix-Version: den gesamten Restaufwand der unerledigten Arbeit, angeordnet als Matrix Benutzer × Vorgangstypen, mit Summen pro Person und pro Vorgangstyp — die „Wer hat noch wie viel wovon“-Sicht der Release-Verantwortlichen.
Warum Burndowns und Gadgets diese Frage nicht beantworten
Das meiste, was Jira für die Verfolgung des Release-Fortschritts anbietet, beantwortet eine andere Frage:
- Der Release Burndown und der Versionsbericht projizieren anhand der Team-Velocity, wann das Release fertig wird — sie zeigen nie, wer die verbleibende Arbeit trägt.
- Vorgangsstatistik- und Tortendiagramm-Gadgets, gruppiert nach Bearbeiter, zählen Vorgänge eines
fixVersion-Filters — den Restaufwand pro Person summieren können sie nicht.
Der Version Workload Report war die einzige native Ansicht des Restaufwands einer Fix-Version pro Bearbeiter — genau das baut die folgende Matrix nach.
Der Nachbau als Report-Builder-Matrix
- Erstellen Sie einen leeren URT-Bericht — die Standard-Visualisierung „Matrix“ ist genau richtig.
- Zeilen: Bearbeiter. Spalten: Vorgangstyp.
- Kennzahl: Summe Restaufwand, „Pretty“-Format („2d 4h“).
- Scope (JQL-Modus):
fixVersion = "1.5" AND resolution IS EMPTY.
Zeilen- und Spaltensummen der Matrix reproduzieren die Auswertungen des alten Berichts pro Person und pro Vorgangstyp, und jede Zelle bietet Drill-down zu den Vorgängen hinter der Zahl — im Bericht selbst oder direkt in der Jira-Vorgangssuche.
Und dann weiter, als der alte Bericht je konnte
- Alle Versionen auf einmal: Fügen Sie Fix-Version als erste Zeilendimension über „Bearbeiter“ hinzu und entfernen Sie die Versionsklausel aus dem Scope. Ein Bericht überwacht jedes offene Release; der alte Bericht zeigte eine Version pro Aufruf.
- Fortschritt statt nur Restaufwand: Ergänzen Sie Summe aufgewendete Zeit und einen Progress-by-Time-Balken.
- Auf dem Dashboard: Bericht speichern und als Report-Builder-Gadget auf ein Jira-Dashboard legen — der alte Bericht kam nie von seiner Projektseite herunter.
- Andere Schnitte: Tauschen Sie Vorgangstyp gegen Priorität, Komponente oder jedes andere Feld.
Warum das die Gadget-Workarounds schlägt: Statistik- und Tortendiagramm-Gadgets zählen Vorgänge; Restaufwände pro Bearbeiter summieren können sie nicht. Diese Matrix zeigt echte Zeitwerte, mit Summen, Drill-down und Dashboard-Präsenz — die drei Dinge, nach denen die Community-Threads zu dieser Abkündigung immer wieder fragen.
Häufige Fragen
Kann ich nicht einfach den Release Burndown nehmen? Er beantwortet „Wann werden wir fertig?“ (Velocity-Projektion über Sprints), nicht „Wer hat noch wie viel Arbeit?“. Beide Ansichten ergänzen sich; nur diese hier zeigt Restaufwände pro Person.
Zählen Unteraufgaben mit? Aktivieren Sie die Scope-Option „Untergeordnete Vorgänge laden“; alternativ stehen Jiras Σ-Aggregatfelder für Roll-ups auf Elternebene bereit.
Kann ich auf ein Team filtern? Ja — erweitern Sie den JQL-Scope oder filtern Sie direkt auf der Bearbeiter-Dimension.
Was ist mit ungeschätzten Vorgängen? Vorgänge ohne Restaufwand tragen nichts zu den Summen bei; ergänzen Sie eine Kennzahl Anzahl Vorgänge, um ungeschätzte Arbeit in einer Zelle sichtbar zu machen.
Unverbindlich