Redmine is not a Scrum tool by default. It does not ship with sprint boards, velocity tracking, or a structured backlog. Teams that try to run agile sprints using only the built-in feature set typically end up tracking sprint work in a version, watching the Gantt chart, and updating a spreadsheet on the side.
In practice, that approach works in the way that a workaround always works until the team grows, the sprint gets more complex, or the project manager needs reliable velocity data for planning.
Fortunately, Redmine handles sprints very well with the right setup. This guide walks through how to run a sprint in Redmine from initial backlog grooming through sprint review including what the Redmineflux Agile Board Plugin adds at each stage.
The short answer: Running a sprint in Redmine means using Versions to define sprint boundaries, Issues to represent sprint work, and a backlog view to plan what enters each sprint. With the Redmineflux Agile Board Plugin, you also get a visual sprint board, WIP limits, velocity tracking, and drag-and-drop sprint planning all working directly on top of your existing Redmine issues.
Before setting up the first sprint, it helps to understand how Redmine’s native structure maps to agile concepts. In Redmine, a Version represents a sprint or release. Issues get assigned to a Version to indicate which sprint they belong to. The backlog is the set of issues not yet assigned to any version.
That structure is the foundation. Everything else the board, the velocity chart, the sprint review builds on top of it.
In Redmine, go to Project → Settings → Versions → New Version. Give the version a sprint name for example, “Sprint 1” or “Sprint 2026-05.” Set a start date and a due date that match your sprint length. Two-week sprints are standard, but Redmine supports any length.
Next, repeat this for each upcoming sprint. In practice, most teams create three to four sprints ahead so the backlog grooming session has somewhere to assign issues. In fact, you do not need every sprint planned in detail just the version names and dates.
The backlog in Redmine is all issues in the project that have no version assigned. To build a usable backlog, create issues for every piece of work the team is tracking bugs, features, tasks, and anything else. Specifically, each issue should have a subject, a tracker type, and a priority. Assignees and estimates can come later.
With the Redmineflux Agile Board Plugin, the backlog view shows all unassigned issues in priority order. Additionally, Story Points appear on each card if the team estimates in points. The backlog is sortable, filterable, and directly actionable you drag issues from the backlog into the sprint column to add them to the current sprint.
Without the plugin, you can still manage the backlog by filtering the issue list by “no version” and sorting by priority. It is less visual, but the underlying data structure is the same.
Want to see the sprint board and backlog in action? Book a Free Demo see a live Redmine environment with the full sprint workflow running in 30 minutes.
Sprint planning in Redmine means deciding which backlog issues move into the current sprint version. Open the sprint planning view in the Agile Board Plugin it shows the backlog on one side and the current sprint on the other. Drag issues across as the team commits to them.
As each issue enters the sprint, confirm the assignee, the estimate, and the acceptance criteria. If issues do not have Story Points yet, this is the moment to add them. As a result, the plugin shows running sprint totals so the team can see immediately when the sprint is at capacity.
For teams using Redmine without the plugin, move issues into the sprint by editing each issue and setting its version to the current sprint. The process is the same it just requires more individual edits rather than drag-and-drop.
Once the sprint is planned, the Agile Board Plugin provides the board view the team uses for daily standups and status tracking. Specifically, each column represents a workflow status typically New, In Progress, In Review, QA, and Done. Issues move across the board as work progresses.
WIP limits keep the board honest. If the team sets a limit of three issues in the In Progress column, the board shows a warning when that limit is hit. That visible constraint is what prevents the common pattern of ten issues “in progress” with none actually moving.
The board updates in real time. When a developer moves an issue to In Review, the QA engineer sees it immediately without checking in or waiting for a daily update. That visibility is what makes the sprint board genuinely useful rather than ceremonial.
During the sprint, the team uses the board for day-to-day status and the burndown chart for progress tracking. Moreover, the plugin generates the burndown chart automatically no manual updates needed. It shows whether the sprint is on track or accumulating scope debt.
Additionally, the Gantt Chart view complements the sprint board for longer delivery horizons. If the current sprint is part of a larger release, the Gantt Chart Plugin shows how the sprint’s completion date fits into the release timeline. Dependencies between issues become visible before they block the sprint.
For time-sensitive projects, the Timesheet Plugin logs hours against sprint issues and surfaces effort data during sprint review. When velocity data combines with actual time logged, the team gets a much more accurate picture of what a sprint genuinely costs.
At the end of the sprint, close completed issues and move any unfinished work back to the backlog or forward into the next sprint. In the Agile Board Plugin, closing the sprint updates the version status to Closed and removes completed issues from the active board. Unfinished issues remain open and appear in the backlog for the next planning session.
The sprint review is also the moment to check velocity. The plugin records the Story Points completed in each sprint. Over three to four sprints, the team’s average velocity becomes reliable enough to use for planning. When sprint five’s planning session opens, the team knows roughly how many points the sprint can hold based on what sprints two through four actually delivered, not on optimistic estimates.
Furthermore, the sprint retrospective happens outside the tool, but the data for it comes from inside. Burndown shape, velocity trend, issue type breakdown, and time logged all sit in Redmine. The retrospective becomes a data-informed conversation rather than a memory exercise.
The native Redmine structure handles the data layer of sprint management. However, the Agile Board Plugin sprint boards, backlog planning, and velocity tracking for Redmine adds the workflow layer that makes the data usable day-to-day.
At planning, it adds drag-and-drop sprint assignment and Story Point capacity visibility. During the sprint, it adds the board view, WIP limits, and burndown tracking. At review, it adds velocity history and sprint close workflow. Together, these transform Redmine from a capable issue tracker into a complete Scrum environment without moving issues into a separate redmine combo sprint tool or maintaining data in two places at once.
Consider a seven-person development team running two-week sprints. They have a backlog of forty issues a mix of features, bugs, and tasks. Their average velocity over the last three sprints is thirty-two Story Points.
At planning, the team opens the sprint board and drags issues from the backlog into Sprint 8 until the total reaches thirty-two points. The team assigns issues, confirms estimates, and checks acceptance criteria. In total, the planning session takes forty-five minutes.
During the sprint, the board runs the daily standup. Each morning, developers move their issues across columns and flag blockers. The burndown chart tracks daily progress. By day eight, the chart shows the sprint is two days behind. As a result, the team adjusts pulling in a smaller issue, deferring a larger one and finishes on time.
At review, the sprint closes with thirty Story Points completed. Velocity stays consistent. The retrospective identifies one recurring blocker. The next sprint’s planning session starts with that blocker already on the agenda to resolve.
That is what a well-run sprint in Redmine looks like in practice.
Redmine uses Versions to define sprint boundaries and Issues to represent sprint work. The native backlog and sprint structure is functional but not visual. The Redmineflux Agile Board Plugin adds drag-and-drop sprint planning, a visual board, WIP limits, Story Points, and velocity tracking on top of the native structure.
Go to Project → Settings → Versions → New Version. Name the version after your sprint, set a start date and due date, and save. Issues assigned to that version belong to the sprint. With the Agile Board Plugin, you assign issues to sprints by dragging them from the backlog into the sprint column during planning.
Yes, with the Redmineflux Agile Board Plugin. The plugin records Story Points completed in each sprint and displays velocity history across sprints. After three to four sprints, the average velocity becomes a reliable planning input for future sprint capacity decisions.
At sprint close, move unfinished issues back to the backlog or forward into the next sprint version. The Agile Board Plugin handles this during the sprint close workflow you choose what to do with each incomplete issue before the sprint officially closes.
In Redmine, a Version is the native container for grouped work. When used for sprints, a Version defines the sprint start and end dates and holds all the issues committed to that sprint. The Agile Board Plugin treats Versions as sprints and builds the board, backlog, and velocity chart around that structure.
Redmineflux tests and supports the Agile Board Plugin on Redmine 5.0.x, 5.1.x, and 6.0.x. Teams running Redmine 4.x should contact support before purchasing to confirm compatibility.
Overall, Redmine handles sprints well when set up correctly. The data structure Versions as sprints, Issues as work items, the backlog as unassigned issues is solid. The Agile Board Plugin adds the visual and workflow layer that makes that structure usable for a real Scrum team day-to-day. Together, they cover the full sprint cycle from planning through review without any data living outside Redmine.
Explore Managed Cloud — Redmine with the full plugin suite pre-configured
