Agile Teams arbeiten in Sprints - also in festen Zeitfenstern von meist ein bis zwei Wochen, in denen das Team gemeinsam auf ein klares Ziel hinarbeitet. In Redmine bildest du solche Sprints ganz einfach mit Versionen ab, und 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 können.
Sprint = Version: Redmine kann das bereits
Bevor wir in die Praxis gehen, eine wichtige Einordnung: Das Reporting Plugin führt keine eigene, separate Sprint-Entität ein. Stattdessen nutzt es die Redmine-Versionen als Sprints - und erweitert diese einfach um das notwendige Enddatum.
Warum? Redmine-Versionen bringen alles mit, was ein Sprint braucht:
- Start- und Enddatum - hier hinterlegst du das Zeitfenster deiner Iteration
- Freigabe über Projekte hinweg - ein Sprint kann bei Bedarf in unterschiedlichen Projekten gemeinsam genutzt werden
- Automatische Integration - Versionen sind relevant für den Burndown Chart, die Roadmap und Fortschrittsanzeige und das 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 Bereiche (Swimlanes): den Backlog, den aktuellen und den nächsten Sprint. Ziehst du ein Ticket aus dem Backlog in die Sprint-Version, passiert beides in einer einzigen Aktion:
- Zielversion wird gesetzt - das Ticket gehört jetzt zum Sprint
- Status wird geändert - z.B. von “Backlog” zu “Sprint bereit”, wenn du gleichzeitig die Statusspalte wechselst
Tipp: Halte beim Ziehen die Shift-Taste, es öffnet sich ein Kommentarfeld - so hältst du direkt fest, warum ein Ticket in diesen Sprint kommt. Und weil das Board alle Workflow-Regeln und Berechtigungen respektiert, kannst du keine ungültigen Übergänge erzeugen: Ein nicht erlaubtes Ticket springt zurück und zeigt eine entsprechende Meldung an.
Das Ergebnis: Das Team sieht in Echtzeit, wie sich der Sprint füllt, und diskutiert über Inhalte statt über Formalitäten. 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 wurde gestern gemacht? Was steht heute an? Gibt es ein Problem? Und wer hat Kapazität für das nächste Ticket? Ein Blick in eine lange Liste 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: Wer 6 Tickets in “In Arbeit” hat und wer keins, ist sofort erkennbar. Zeit zum Umverteilen.
- Zuweisung in Sekunden: Über die Avatar Bar ziehst du einen Kollegen direkt auf ein unbesetztes Ticket - kein Ticket öffnen, kein Dropdown. Das System merkt sich häufig genutzte Personen automatisch.
- Engpässe sichtbar machen: Stauen sich Tickets in “Review”, während “In Arbeit” leer läuft, habt ihr ein Prozessproblem im Sprint - nicht erst am Sprint-Ende, sondern jetzt.
Farbliche Kennzeichnung (z.B. nach Tracker: Bugs rot, Features blau) macht relevante Unterschiede zusätzlich sofort sichtbar. Und wer im Team lieber ein reines Kanban ohne feste Sprints fährt, nutzt dasselbe Board einfach ohne Versionsgruppierung weiter. Zusätzlich kann man auch mit einem WiP-Limit arbeiten.
Das Ergebnis: Das Daily dauert wieder 15 Minuten. Jeder pflegt seinen Status per Drag & Drop selbst, die Diskussion konzentriert sich auf echte Blocker, und niemand fragt mehr “Wo steht mein Ticket eigentlich?”.
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 - und du siehst es früh genug, um Ressourcen zu verschieben oder den Scope anzupassen. Am praktischsten 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 präsentierst dem Management keine vagen Einschätzungen, sondern konkrete Verläufe: “Sprint 14 in Team A liegt seit Tag 4 über der Ideallinie, hier steuern wir gegen. Team B ist im Plan.”
Die gespeicherte Abfrage
Egal ob Sprint-Planung, tägliche Team-Arbeit oder Fortschrittskontrolle - die eigentliche Stärke liegt in den benutzerdefinierten Abfragen, die Redmine bereit stellt. Du richtest eine Baord-Ansicht einmal ein und speicherst Filter, Gruppierung, Spaltenauswahl und Farbschema als Teil der Abfrage. Danach steht sie dir und deinem Team jederzeit per Klick zur Verfügung. Und das Tolle daran -> du hast 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 wird aus einzelnen Funktionen ein durchgängiger agiler Arbeitsablauf.
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: Datenpflege lohnt sich: Nur mit gepflegten Start- und Enddaten entfalten Burndown und Roadmap ihren vollen Nutzen. Die Tickets selbst benötigen keine Datumsangabe, die wird automatisch von der zugewiesenen Version übernommen. Das hat den Vorteil, dass man einfach nur die Versionszuweisung ändern muss und die Datumsangaben passen sich automatisch im Ticket an.
Fazit
Das Reporting-Taskboard macht Redmine zu einem praxistauglichen Sprint-Werkzeug: Planung, tägliche Arbeit und Fortschrittskontrolle laufen an einem Ort, ohne neue Methodik und ohne Toolwechsel. Die Boardansicht ist nämlich einfach nur eine andere Darstellung der Ticketliste.
Es ist kein 100% Ersatz für ein dediziertes Scrum-Tool: Wenn dein Team zwingend eines der folgenden Dinge braucht, ist der aktuelle Funktionsumfang nicht ausreichend:
- 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 Sprint oder Release, nicht beidem gleichzeitig.
- Story Points und Velocity - Schätzpunkte lassen sich als benutzerdefiniertes Feld abbilden, einen nativen Velocity-Chart gibt es aber nicht.
Die meisten Teams, die nicht strikt agil arbeiten, Redmine Reporting ohnehin installiert haben und den pragmatischen Ansatz bevorzugen, werden mit dem Funktionsumfang im Alltag jedoch gut zurechtkommen.
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.