Agile teams work in sprints - in fixed time frames of usually one or two weeks in which the team works towards a clear goal together. In Redmine you map such sprints very easily with versions, and the Taskboard of the Reporting Plugin turns them into an interactive planning board.
In this article you will learn how scrum masters, teams and management can use the Reporting Plugin for their sprint and version planning.
Sprint = version: Redmine can already do this
Before we get practical, an important clarification: The Reporting Plugin does not introduce a separate sprint entity of its own. Instead it uses the Redmine versions as sprints - and simply extends them with the necessary end date.
Why? Redmine versions bring along everything a sprint needs:
- Start and end date - here you store the time frame of your iteration
- Sharing across projects - a sprint can be used jointly in different projects if required
- Automatic integration - versions are relevant for the burndown chart, the roadmap and the progress display, without any additional effort
So you do not have to learn a second concept and do not have to maintain a parallel data structure. A “backlog” is simply a status of its own, or a version in which you collect unplanned issues. A “sprint” is a version with the time frame you define. The Reporting Plugin adds exactly the tools you are missing in the Redmine standard: the visual planning board and the graphical evaluation (burndown chart).
For scrum masters and project managers: sprint planning via drag & drop
The situation: Sprint planning meeting. In front of you are 60 issues in the backlog, and within the next 45 minutes they are supposed to become a full sprint. In the classic issue list this would mean: open every issue, set the target version, save, back to the list. With 20 issues to plan, the meeting is over before the planning is finished.
The solution: You open the Taskboard of the Reporting Plugin and group it by version. Now you see your versions as areas (swimlanes): the backlog, the current and the next sprint. If you drag an issue from the backlog into the sprint version, both things happen in a single action:
- The target version is set - the issue now belongs to the sprint
- The status is changed - for example from “Backlog” to “Ready for sprint”, if you change the status column at the same time
Tip: Hold the Shift key while dragging and a comment field opens - this way you record directly why an issue goes into this sprint. And because the board respects all workflow rules and permissions, you cannot create invalid transitions: An issue that is not allowed jumps back and displays a corresponding message.
The result: The team sees in real time how the sprint fills up and discusses content instead of formalities. For entire packages of issues you additionally use the bulk edit actions (select the relevant issues, right click, Redmine bulk edit) and assign the desired version to several issues at once.
For teams: working through the sprint
The situation: The sprint is running. In the daily scrum the team members ask themselves their usual questions: What was done yesterday? What is on the agenda today? Is there a problem? And who has capacity for the next issue? A glance at a long list answers none of these questions quickly.
The solution: You filter the board on the current sprint version and group by assignee. Now every team member has their own row across all status columns:
- Workload distribution at a glance: Who has 6 issues in “In Progress” and who has none is immediately visible. Time to redistribute.
- Assignment in seconds: Using the avatar bar you drag a colleague directly onto an unassigned issue - no opening of issues, no dropdown. The system automatically remembers frequently used people.
- Making bottlenecks visible: If issues pile up in “Review” while “In Progress” runs empty, you have a process problem in the sprint - not only at the end of the sprint, but now.
Colour coding (for example by tracker: bugs red, features blue) makes relevant differences immediately visible as well. And if your team prefers plain Kanban without fixed sprints, you simply keep using the same board without version grouping. In addition you can work with a WIP limit.
The result: The daily takes 15 minutes again. Everyone maintains their own status via drag & drop, the discussion concentrates on real blockers, and nobody asks “Where does my issue actually stand?” any more.
For management and admins: progress and portfolio
The situation: You are responsible for several parallel teams and releases. Management wants to know: Will we manage the sprint? Where do releases overlap? And is a team falling behind its goal before it is too late?
The solution: Because your sprints are real Redmine versions, you can use them directly for the graphical evaluations of the Reporting Plugin.
Burndown chart for the individual sprint:
The burndown chart shows three lines for every version: the theoretical ideal line, the issues (or hours) actually open and all issues including newly added ones. If the actual line lies above the ideal line, the team is falling behind - and you see it early enough to shift resources or adjust the scope. Most practical as a dashboard block directly on the project overview.
Roadmap for the portfolio:
The roadmap view presents your versions on a time-based axis. Via the version list you immediately recognise how sprints and releases are distributed across the teams and where critical phases coincide.
Sharing sprints across teams: Because sprints are based on versions, you can share them via the standard sharing options - with subprojects, the project hierarchy, the project tree or all projects. Several teams thus plan the same release together, and the cross-project Taskboard view bundles all issues involved in one place.
The result: You do not present vague estimates to management, but concrete developments: “Sprint 14 in team A has been above the ideal line since day 4, we are counteracting here. Team B is on schedule.”
The saved query
Whether sprint planning, daily team work or progress monitoring - the actual strength lies in the custom queries Redmine provides. You set up a board view once and save filters, grouping, column selection and colour scheme as part of the query. After that it is available to you and your team at any time with one click. And the great thing about it: you always have the usual issue filters and columns to choose from.
The following have proven themselves, for example:
- “Sprint planning” - board grouped by version, for the planning meeting
- “Our sprint” - board filtered on the active version, grouped by users, for the daily scrum meeting
- “Release progress” - burndown block on the project dashboard, for the management view
This is how individual functions become a consistent agile workflow.
How to set up your sprint planning
- Create versions: Under Project settings / Versions create your sprints with a start and end date. Alternatively, a version without a date can serve as a backlog.
- Open the board: Go to the Issues area, open the Options and select the option Board under Display results as.
- Group by target version: Under Group results by select Target version - now you can drag issues between the backlog and the sprints.
- Save the view: Save the configuration as a custom query, optionally shared with your team.
- Activate progress tracking: An administrator activates the burndown chart under Plugins / Redmine Reporting / General (option Display burndown chart for versions).
Requirements: Maintaining your data pays off: Burndown and roadmap only develop their full benefit with properly maintained start and end dates. The issues themselves do not need a date, it is automatically taken from the assigned version. This has the advantage that you only have to change the version assignment and the dates in the issue adjust automatically.
Conclusion
The Reporting Taskboard turns Redmine into a sprint tool suitable for everyday use: planning, daily work and progress monitoring run in one place, without new methodology and without switching tools. After all, the board view is simply a different representation of the issue list.
It is not a 100% replacement for a dedicated scrum tool: If your team absolutely needs one of the following things, the current range of functions is not sufficient:
- Backlog prioritisation via drag & drop - on the board, filters and sorting determine the order, a manual ranking is only possible via a position field (this is planned as an extension).
- Separate sprint and release levels - an issue belongs to exactly one version, so either a sprint or a release, not both at the same time.
- Story points and velocity - estimation points can be mapped as a custom field, but there is no native velocity chart.
Most teams that do not work strictly agile, that have Redmine Reporting installed anyway and prefer the pragmatic approach will get along well with the range of functions in everyday work.
All information about our extensions for Redmine can be found on the product page. The Reporting Plugin is subject to a fee and is available separately or as part of our Business-Class Bundle as well as the Enterprise+ Bundle. The function described here can be tested extensively in our online demo.