Sprint planning and release planning are not the same problem.
Sprint planning is a two-week cycle. The team commits to a set of issues, delivers them, and closes the sprint. The Agile Board Plugin handles this well issues move through columns, daily stand-ups track blockers, and the sprint closes with a clear record of what shipped.
Release planning operates at a different scale. A software release typically spans multiple sprints. It has external dependencies — the API must be complete before the front-end can integrate, the staging environment must be ready before QA can run, legal review must finish before the release date is confirmed. It has milestone commitments made to clients or stakeholders. And it has a history the original plan against which the current state must be compared at every sprint review.
The agile board does not handle that level. The Redmineflux Gantt Chart Plugin does with dependency tracking, milestone markers, and baseline comparison built directly inside Redmine.
The short answer: Sprint boards track daily execution within a two-week cycle. Release planning requires a different layer phase dependencies showing which work blocks which, milestone markers representing external commitments, and baseline comparison showing how the timeline has moved from the original plan. The Redmineflux Gantt Chart Plugin adds all three directly inside Redmine, operating on the same issues the team tracks on the sprint board.
A typical software release involves phases that depend on each other in sequence. Design must finish before development begins. Development must be code-complete before QA can start a full regression. QA sign-off must happen before the deployment window opens.
Without dependency tracking, those relationships live only in the team’s collective memory. When design overruns by four days, someone needs to manually recalculate whether QA still has enough time before the release date. That calculation happens too late in a stand-up, after the damage is already done.
Furthermore, release plans are made to stakeholders and clients. The milestone “version 2.4 ships on June 15” is a commitment, not an estimate. When the timeline shifts, the project manager needs to show exactly how far the current schedule has moved from the original commitment. A sprint board cannot produce that view.
The setup for release planning on the Gantt chart follows a consistent pattern: map the release phases to Redmine issues and versions, link the phases with dependencies, mark the milestones, and save a baseline before work begins.
In Redmine, versions represent sprints or release milestones. For release planning, create one version per release phase Design, Development, QA, Deployment each with a target due date. Go to Project → Settings → Versions → New Version for each phase.
Each version appears on the Gantt chart as a milestone marker at its due date. The project manager sees the full release timeline phase by phase before any dependency lines are added.
For each issue in the release, assign it to the version (phase) it belongs to. Design tasks go to the Design version, development tasks go to the Development version, and so on. Issues assigned to a version group together under that milestone on the Gantt chart.
This grouping shows at a glance how many issues sit in each phase and how they distribute across the timeline. If development issues are scheduled after the QA milestone, the Gantt makes that conflict visible immediately.
Open any issue that cannot start until another issue completes. In the Relations section of the issue, add a “follows” relation pointing to the predecessor. Save the issue.
Back on the Gantt chart, a dependency arrow appears between the two issues. When the predecessor’s due date is later than the dependent issue’s start date, the Gantt shows the conflict. For a release with four sequential phases, add three dependency links: Development follows Design, QA follows Development, Deployment follows QA.
That chain defines the critical path. Any slip in Design now shows its downstream impact on QA and the release date automatically without any manual calculation.
Before the release begins active execution, save the current schedule as a baseline. On the Gantt chart view, click Set Baseline. The plugin stores every issue’s start and due date as the reference plan.
From that point forward, the Gantt displays two bars for every issue: the baseline bar showing the original planned dates, and the current bar showing today’s dates. When an issue moves, the gap between the two bars shows the slippage no manual comparison needed.
Save a new baseline at the start of each sprint within the release cycle. That creates a record of how the release timeline evolved useful for retrospectives and client-facing reporting.
Want to see release planning with dependencies and baselines in a live Redmine environment? Book a Free Demo → 30 minutes covers the full release Gantt setup from phase mapping to baseline tracking.
The most practical use of the release Gantt is the sprint review check-in. At the end of each sprint within the release cycle, the project manager opens the Gantt and reads three signals:
How far have issue dates moved from the baseline?
The baseline comparison shows, for every remaining issue, how many days it has shifted from the original plan. An issue planned to start on June 1 but currently scheduled for June 7 shows a six-day slip on the baseline bar.
Are any dependencies now in conflict?
When issues slip, the dependency arrows show whether the slip has created a downstream conflict. If the Development phase slipped four days and QA was planned to start the day after Development’s original due date, the Gantt shows the overlap immediately.
Is the release milestone still achievable?
The milestone marker shows the committed release date. The project manager can see whether the current issue schedule still delivers before that date or whether the milestone needs to be renegotiated.
These three signals come from a single view. The project manager reads them in two minutes at the start of each sprint review rather than spending time rebuilding the picture manually from individual issue filters.
The Gantt chart operates on the same issues the team tracks on the sprint board. There is no separate planning layer and no data to synchronise.
The Agile Board Plugin handles sprint-level execution. When a developer closes an issue on the sprint board, the corresponding bar on the Gantt chart updates automatically. The project manager and the development team are always looking at the same underlying data — from different angles.
Logged time from the Timesheet Plugin connects to the same issues displayed on the Gantt. When an issue takes longer than estimated, the time log explains why the bar moved. The project manager can see both the schedule impact and the effort variance from one system.
The Workload Plugin shows team capacity across the same timeline the Gantt displays. Before rescheduling an issue on the Gantt, the project manager can confirm the assigned developer has capacity on those dates — avoiding overloads that create further slips.
For teams that want the release health view alongside sprint metrics, the Custom Dashboard Plugin shows upcoming milestones from Gantt versions as a dashboard widget so the project manager sees release proximity without opening the Gantt view separately.
Common Questions
What is a Finish-to-Start dependency in Redmine Gantt?
A Finish-to-Start dependency means Issue B cannot start until Issue A is complete. In the Redmineflux Gantt Chart Plugin, you set this by adding a “follows” relation on Issue B pointing to Issue A. When Issue A slips, the chart shows the downstream impact on Issue B automatically no manual recalculation required.
How do I track release milestones on a Redmine Gantt chart?
Create a Redmine version with a due date for each milestone in Project → Settings → Versions. The Redmineflux Gantt Chart Plugin displays each version as a milestone marker on the Gantt timeline. Issues assigned to that version group under the milestone in a single view alongside all the issues working toward it.
What is a Gantt baseline and why does it matter for release planning?
A baseline is a saved snapshot of the release schedule at a specific point in time typically project kickoff or the start of each sprint. The plugin stores baseline dates separately from the live schedule. As the release progresses, the Gantt shows both the original plan and the current schedule side by side essential for client reporting and retrospective review.
Can I view multiple sprints on a single Gantt chart for release planning?
Yes. The Redmineflux Gantt Chart Plugin displays all issues across a project’s versions on a single timeline. You can view every sprint and phase within a release on one chart with milestone markers, dependency arrows, and baseline comparison across the full release scope.
Can I export the release Gantt to PDF for client reporting?
Yes. The Redmineflux Gantt Chart Plugin includes PDF and PNG export. The exported chart includes the current schedule, baseline comparison if a baseline has been saved, and dependency arrows formatted for client status reports and release sign-off documents.
Which Redmine versions does the Gantt Chart Plugin support?
Redmineflux tests and supports the Gantt Chart 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.
Sprint boards keep daily delivery on track. The Redmine Gantt Chart Plugin keeps the release on track with the dependency chain, milestone markers, and baseline comparison that tell the project manager whether the original commitment is still achievable. Both views draw from the same Redmine issues. The team sees the work from two angles without managing two systems.
Explore Managed Cloud → Redmine with the Gantt Chart Plugin and full plugin suite pre-installed, hosted, and managed.
