Agile Teams arbeiten in Sprints, also in festen Zeitfenstern von meist ein bis zwei Wochen, in denen das Team auf ein klares Ziel hinarbeitet. In Redmine bildest du solche Sprints mit Versionen ab. Das Taskboard des Reporting Plugins macht daraus ein interaktives Planungsboard.
In diesem Beitrag erfährst du, wie Scrum Master, Teams und das Management das Reporting Plugin für ihre Sprint- und Versionsplanung nutzen.
Sprint = Version: Redmine kann das bereits
Das Reporting Plugin führt keine eigene, separate Sprint-Entität ein. Es nutzt die Redmine-Versionen als Sprints und erweitert sie um das notwendige Enddatum.
Redmine-Versionen bringen nämlich alles mit, was ein Sprint braucht:
- Start- und Enddatum: hier hinterlegst du das Zeitfenster deiner Iteration
- Freigabe über Projekte hinweg: mehrere Projekte können denselben Sprint nutzen
- Automatische Integration: Versionen speisen Burndown Chart, Roadmap und Fortschrittsanzeige ohne Zusatzaufwand
Du musst also kein zweites Konzept lernen und keine parallele Datenstruktur pflegen. Ein “Backlog” ist einfach ein eigener Status, oder eine Version, in der du ungeplante Tickets sammelst. Ein “Sprint” ist eine Version mit dem von dir definierten Zeitfenster. Das Reporting Plugin ergänzt genau die Werkzeuge, die dir im Redmine-Standard fehlen: das visuelle Planungsboard und die grafische Auswertung (Burndown-Chart).
Für Scrum Master und Projektleiter: Sprint Planning per Drag & Drop
Die Situation: Sprint-Planning-Meeting. Vor dir liegen 60 Tickets im Backlog, und in den nächsten 45 Minuten soll daraus ein voller Sprint werden. In der klassischen Ticketliste hieße das: jedes Ticket öffnen, Zielversion setzen, speichern, zurück zur Liste. Bei 20 einzuplanenden Tickets ist das Meeting vorbei, bevor die Planung fertig ist.
Die Lösung: Du öffnest das Taskboard des Reporting-Plugins und gruppierst es nach Version. Jetzt siehst du deine Versionen als Swimlanes, also als eigene waagrechte Zeilen: den Backlog, den aktuellen und den nächsten Sprint. Ziehst du ein Ticket aus dem Backlog in die Sprint-Version, erledigt diese eine Aktion beides:
- Sie setzt die Zielversion, das Ticket gehört jetzt zum Sprint
- Sie ändert den Status, zum Beispiel von “Backlog” zu “Sprint bereit”, wenn du gleichzeitig die Statusspalte wechselst
Tipp: Halte beim Ziehen die Shift-Taste gedrückt, dann öffnet sich ein Kommentarfeld. Dort hältst du fest, warum ein Ticket in diesen Sprint kommt. Das Board beachtet außerdem alle Workflow-Regeln und Berechtigungen. Ein nicht erlaubter Übergang springt zurück und zeigt eine Meldung an.
Das Ergebnis: Das Team sieht in Echtzeit, wie sich der Sprint füllt. Für ganze Ticket-Pakete nutzt du zusätzlich die Bulk-Edit Aktionen (relevante Tickets auswählen, Rechtsklick, Redmine-Bulk-Edit) und weist mehreren Tickets auf einmal die gewünschte Version zu.
Für Teams: Den Sprint abarbeiten
Die Situation: Der Sprint läuft. Im Daily Scrum stellen sich die Team-Mitglieder ihre üblichen Fragen: Was habe ich gestern gemacht? Was steht heute an? Gibt es ein Problem? Und wer hat Kapazität für das nächste Ticket? Eine lange Ticketliste beantwortet keine dieser Fragen schnell.
Die Lösung: Ihr filtert das Board auf die aktuelle Sprint-Version und gruppiert nach Zugewiesen an. Jetzt hat jedes Teammitglied seine eigene Zeile über alle Statusspalten hinweg:
- Lastverteilung auf einen Blick: Du siehst sofort, wer 6 Tickets in “In Arbeit” hat und wer keins. Zeit zum Umverteilen.
- Zuweisung in Sekunden: Über die Avatar Bar ziehst du einen Kollegen direkt auf ein unbesetztes Ticket, ohne Ticket zu öffnen und ohne Dropdown. Häufig genutzte Personen merkt sich das System automatisch.
- Engpässe sichtbar machen: Stauen sich Tickets in “Review”, während “In Arbeit” leer läuft, habt ihr ein Prozessproblem im Sprint. Und zwar jetzt und nicht erst am Sprint-Ende.
Zusätzlich färbst du die Karten ein, zum Beispiel nach Tracker. Dann erkennt ihr Bugs und Features schon an der Farbe:
Wer lieber ein reines Kanban ohne feste Sprints fährt, nutzt dasselbe Board ohne Versionsgruppierung weiter, bei Bedarf mit einem WIP-Limit.
Das Ergebnis: Jeder pflegt seinen Status per Drag & Drop selbst und die Diskussion im Daily dreht sich um echte Blocker.
Für Management und Admins: Fortschritt und Portfolio
Die Situation: Du verantwortest mehrere parallele Teams und Releases. Die Geschäftsführung will wissen: Schaffen wir den Sprint? Wo überschneiden sich Releases? Und läuft ein Team seinem Ziel hinterher, bevor es zu spät ist?
Die Lösung: Weil deine Sprints echte Redmine-Versionen sind, kannst du sie direkt für die grafischen Auswertungen des Reporting Plugins nutzen.
Burndown Chart für den einzelnen Sprint:
Der Burndown Chart zeigt für jede Version drei Linien: die theoretische Ideallinie, die tatsächlich offenen Tickets (bzw. Stunden) und alle Tickets inklusive neu hinzugekommener. Liegt die Ist-Linie über der Ideallinie, hängt das Team hinterher. Du siehst das früh genug, um Ressourcen zu verschieben oder den Umfang anzupassen. Am praktischsten ist der Chart als Dashboard-Block direkt auf der Projektübersicht.
Roadmap für das Portfolio:
Die Roadmap-Ansicht stellt deine Versionen zeitbasiert auf einer Achse dar. Über die Versionsliste erkennst du sofort, wie sich Sprints und Releases über die Teams verteilen und wo kritische Phasen zusammenfallen.
Sprints teamübergreifend teilen: Weil Sprints auf Versionen basieren, kannst du sie über die Standard-Freigabe teilen: mit Unterprojekten, der Projekthierarchie, dem Projektbaum oder allen Projekten. Mehrere Teams planen so denselben Release gemeinsam, und die projektübergreifende Taskboard-Ansicht bündelt alle beteiligten Tickets an einem Ort.
Das Ergebnis: Du zeigst dem Management konkrete Verläufe statt Einschätzungen: “Sprint 14 in Team A liegt seit Tag 4 über der Ideallinie, hier steuern wir gegen. Team B ist im Plan.”
Die gespeicherte Abfrage
Ob Sprint-Planung, tägliche Team-Arbeit oder Fortschrittskontrolle: Die eigentliche Stärke liegt in den benutzerdefinierten Abfragen, die Redmine bereitstellt. Du richtest eine Board-Ansicht einmal ein und speicherst Filter, Gruppierung, Spaltenauswahl und Farbschema als Teil der Abfrage. Danach steht sie dir und deinem Team per Klick zur Verfügung. Dabei hast du immer die üblichen Ticketfilter und Spalten zur Auswahl.
Bewährt haben sich zum Beispiel:
- “Sprint Planning”: Board gruppiert nach Version, für das Planungsmeeting
- “Unser Sprint”: Board gefiltert auf die aktive Version, gruppiert nach Benutzern, für das Daily Scrum Meeting
- “Release-Fortschritt”: Burndown-Block auf dem Projekt-Dashboard, für den Management-Blick
So richtest du deine Sprint-Planung ein
- Versionen anlegen: Erstelle unter Projekt-Einstellungen / Versionen deine Sprints mit Start- und Enddatum. Eine Version ohne Datum kann alternativ als Backlog dienen.
- Board öffnen: Gehe in den Bereich Tickets, öffne die Optionen und wähle bei Ergebnisse anzeigen als die Option Board.
- Nach Zielversion gruppieren: Unter Gruppiere Ergebnisse nach wählst du Zielversion. Jetzt kannst du Tickets zwischen Backlog und Sprints ziehen.
- Ansicht speichern: Sichere die Konfiguration als benutzerdefinierte Abfrage, optional geteilt mit deinem Team.
- Fortschritt aktivieren: Ein Administrator aktiviert den Burndown Chart unter Plugins / Redmine Reporting / Allgemein (Option Burndown-Chart für Versionen anzeigen).
Voraussetzungen: Die Datenpflege lohnt sich. Burndown und Roadmap funktionieren nur mit gepflegten Start- und Enddaten. Die Tickets selbst brauchen keine Datumsangabe, sie übernehmen die Daten der zugewiesenen Version. Du änderst also nur die Versionszuweisung und die Datumsangaben im Ticket passen sich an.
Fazit
Planung, tägliche Arbeit und Fortschrittskontrolle laufen mit dem Reporting-Taskboard an einem Ort, ohne neue Methodik und ohne Toolwechsel. Die Boardansicht ist nämlich nur eine andere Darstellung der Ticketliste.
Ein dediziertes Scrum-Tool ersetzt es nicht zu 100 Prozent. Braucht dein Team zwingend eines der folgenden Dinge, reicht der aktuelle Funktionsumfang nicht:
- Backlog-Priorisierung per Drag & Drop: Im Board bestimmen Filter und Sortierung die Reihenfolge, ein manuelles Ranking geht nur über ein Positions-Feld (ist als Erweiterung angedacht).
- Getrennte Sprint- und Release-Ebenen: Ein Ticket gehört zu genau einer Version, also entweder zum Sprint oder zum Release, nicht zu beidem gleichzeitig.
- Story Points und Velocity: Schätzpunkte lassen sich als benutzerdefiniertes Feld abbilden, einen nativen Velocity-Chart gibt es aber nicht.
Für alle anderen reicht der Funktionsumfang im Alltag gut aus, vor allem wenn ihr nicht strikt agil arbeitet und Redmine Reporting ohnehin installiert habt.
Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Das kostenpflichtige Reporting Plugin gibt es einzeln oder als Teil unseres Business-Class Bundle, sowie dem Enterprise+ Bundle. Die hier beschriebene Funktion kann in unserer Online-Demo ausgiebig getestet werden.