Agile Gantt charts: plan releases and dependencies

Does agile actually rule out a Gantt chart?

No. The Agile Manifesto values responding to change over following a plan, while recognising value in both. A timeline is compatible with that: the question is whether the team updates its forecast when it learns something new.

The Scrum Guide sets sprints at one month or less and allows scope to be clarified as the team learns, without endangering the Sprint Goal. It does not prescribe Gantt charts. A release chart should support inspection and adaptation, not turn distant estimates into fixed commitments.

PMI's Disciplined Agile guidance names the real reason so many agile teams refuse charts. In its note on Gantt charts and agile planning, it says teams have often seen them abused, packed with detail that had to be maintained as things changed, which added needless overhead. Its advice is to keep them high level and use them to track critical dependencies and dates. That is a fair summary of the whole argument.

Which level of an agile plan suits a Gantt chart?

The release level is a useful starting point. Some teams also use a high-level roadmap; others have integrated tools that show sprint tasks on a timeline without duplicate maintenance. Choose the detail that helps your team make decisions.

It helps to think of an agile plan as three layers that change at different speeds:

A release chart is useful when several teams need a shared forecast. If you deploy continuously with no coordinated release events, you may only need a few outside dates and milestones. A Kanban team can use the same approach without sprint bars, forecasting delivery from recent throughput or cycle times.

When is a release chart worth keeping?

When the release depends on dates and work the team does not control. The more of the items below a release has, the more a chart pays for itself:

• Fixed outside dates. A conference demo, a contract milestone, a regulatory deadline, a seasonal peak. The team cannot negotiate these at sprint planning, so they need to sit somewhere everyone can see the distance to them.
• Work owed by other teams. An API from the platform team, a security review, a design system update. These are the links between tasks that may be hard to follow on a basic board, and they are usually what actually decides the release date.
• Non-software work around the release. Release notes, help pages, support training, a launch email, app store review. Some can start early; final screenshots, training or sign-off may depend on a stable release. Link only those real handoffs.
• Approval gates. In a PMI case study of a hybrid federal software programme, every release needed sign-off from a change control board that required advance notice, so the authors note that the time to get in front of the board had to be in the project schedule. Any approval with a queue belongs on the chart.
• People who read dates, not boards. Sales, support and leadership want to know what lands this quarter. A chart answers that without them learning your tracker.

That PMI case is a useful picture of the hybrid working at scale. The programme ran four quarterly releases a year, each made of six two-week sprints, with the government's formal requirements and testing met once per release and agile sprints in between. The waterfall layer ran on dates and the agile layer on a backlog, and neither tried to do the other's job.

Where does a Gantt chart hurt an agile team?

It hurts when the chart becomes a second backlog that someone maintains by hand. If the same story change needs updating in two places, simplify the release view or use one shared data source.

The specific ways it goes wrong are predictable:

• Stories as bars. Manually placing forty stories across six future sprints creates a lot of dates to maintain. A board usually handles that changing detail more easily.
• Exact dates three months out. PMI's Disciplined Agile note calls exact estimated dates poor practice, because a scheduling tool calculates precise dates and implies more certainty than exists. Show a launch window instead of a single day when you share it.
• The chart as a contract. The Scrum Guide says sprint scope may be clarified and renegotiated with the product owner as more is learned. A chart treated as a fixed promise removes that freedom, and the team stops telling the truth about what will fit.
• Stretching a sprint bar. A sprint is a fixed timebox. When work does not fit, the scope moves to a later sprint or out of the release. A sprint bar that grows from two weeks to three is a sign the chart is being used to hide a slip.
• Maintaining it without the team. A programme manager can coordinate the chart, but needs the people doing the work to check its assumptions and forecasts.

What a hybrid release plan looks like, worked through

Here is a plausible quarter for a small product team shipping version 3.0 of a booking app: five developers, a designer and a product owner, with a platform team, a security team, docs, support and marketing around them. The release plan fits on one screen, and none of the sprint work appears on it.

For this example, the team keeps its usual two-week sprints and forecasts six of them from recent delivery, expected availability and the work still needed.

The chart has three lists, each shown as a summary bar. Ganttile draws a milestone as a one-day marker, so each milestone here is linked finish-to-finish from the bars it closes: it sits on their last day and adds no day of its own.

1. Sprints. Dev team: Sprint 1 to Dev team: Sprint 6, two weeks each, linked finish-to-start. A milestone called Feature freeze sits at the end of Sprint 5 (week 10) and Release candidate at the end of Sprint 6 (week 12).
2. Payments. Platform: payments API v2 runs weeks 1 to 6 and ends on a Payments API available milestone. Dev team: payment screens is a two-week release item linked from that milestone, and linked to Feature freeze finish-to-finish, so it has to finish on or before the freeze. It records that two weeks of payment work have to fit between the API arriving and the freeze, whichever sprint the board puts them in. As planned, it sits in weeks 7 and 8, with two weeks to spare.
3. Launch. Security: security review in week 11 and Docs: release notes and help pages in weeks 11 and 12, both after Feature freeze. Support: support training in week 13, after the release notes. Product: app store review in week 13, after Release candidate. A Go live milestone at the end of week 13 waits for the store review, the security review and support training, and Marketing: launch email is a one-day task straight after it.

Stories, estimates and bugs stay in the tracker. The payment screens row is a release-level dependency: the team still plans that work within its sprints.

Now the useful part. In week 4 the platform team says the payments API will be two weeks late, landing at the end of week 8 instead of week 6. On the board, that is a backlog conversation: nothing in Sprints 3 and 4 needed the API, so the stories stay where they are. On the chart, with Auto schedule turned on, the API bar gets two weeks longer and the payment screens item moves to weeks 9 and 10. It now finishes on the same day as Feature freeze, which the finish-to-finish link allows, so the freeze stays at the end of Sprint 5, no other date moves and no sprint bar changes. The two weeks to spare are gone, though, and with Critical path turned on, the API and the payment screens now show on the chain that decides the launch date. The product owner can tell stakeholders the date holds and there is no slack left in it.

In week 8 it slips again, to the end of week 10. The payment screens item now runs through weeks 11 and 12, and the finish-to-finish link pushes Feature freeze to the end of week 12, two weeks past the end of Sprint 5. The security review, docs and support training move with it, and Go live lands at the end of week 15. The sprint bars stay where they are, because a sprint is a fixed box, so a freeze that has drifted to the end of Sprint 6, the same day as Release candidate, puts the real choice in front of the product owner. Export a PDF of the chart as it stands, then try each option in turn and export the result, so the versions can be compared before anyone is told anything:

• Keep payments in 3.0. Add Dev team: Sprint 7 (weeks 13 and 14) after Sprint 6, link Feature freeze to Sprint 6 instead of Sprint 5, and Release candidate to Sprint 7. The security review runs in week 13 and the docs in weeks 13 and 14, support training and the store review in week 15, and Go live stays at the end of week 15, two weeks late. Marketing sees its email move on the same chart the developers use.
• Hold the date. Move the payment screens item out of the release, to a 3.1 list, and remove its link to Feature freeze. The freeze drops back to the end of Sprint 5, and Go live returns to the end of week 13.

The chart makes the alternatives visible to developers, support and marketing before anyone promises a date. The team still has to check capacity and agree the choice.

How often should the release chart change?

Review the release forecast at least once a sprint, and update it whenever new information changes the expected dates. The sprint review is a useful point to discuss the result with stakeholders; there is no reason to wait for it when a supplier announces a delay.

A short routine for each review:

1. Mark the finished sprint done. Do not change its length, even if the sprint went badly.
2. Ask whether the remaining sprints can still hold the scope the release needs. If not, the answer is a later sprint added to the end, or scope taken out. Both are visible decisions.
3. Check the other teams' bars against what those teams now say, and move any that changed.
4. With Critical path turned on, look at what the path runs through. If it now runs through something outside the team, that is the item to chase this sprint.
5. Invite the people who update the plan, such as the platform and launch leads, through Ganttile's linked Breeze account; they can view and edit the same chart for free. Export a PDF or image for the people who follow the release but never open the plan.

If every story change triggers a manual chart edit, consider whether the chart has too much detail. Keep the release forecast current, but let the tracker hold daily task changes.

Build a release view your team can maintain

Keep sprint timeboxes fixed and change the forecast scope or number of sprints when needed. Make outside dependencies visible, and review the chart with the people doing the work.