All templates
Gantt template
Software release phases
Timeline from development freeze through production deployment and post-release.
Every software release has the same skeleton: freeze features, test, stage, deploy, and monitor. But teams rarely agree on the timelines and handoff points — dev thinks staging should be 1 day, QA thinks 3, and nobody knows if production rollout happens in parallel with sign-off or after. This template shows the critical path in one Gantt chart: when each phase starts, which can overlap, and where one team's done is another's start gate.
When to use this template
- Planning a release — estimate each phase, spot which are on the critical path, and share the timeline with product and leadership before the sprint ends.
- Post-mortems on slow releases — if your last release took 3 weeks, map it in this diagram and ask which phase bloated. Often it's waiting for staging capacity or a production incident that wasn't planned.
- Onboarding new teams — show them what "done" means for dev, QA, and ops, and when they hand off to the next stage.
How to adapt it
Start by filling in your real phase durations — feature lock to QA lock, QA to staging sign-off, staging to production. Then add your wrinkles:
- Multiple features or tracks — add a row per feature if they move at different speeds (e.g., frontend ships on day 5, backend on day 7).
- Hotfix lanes — if critical bugs require a separate 1–2 day cycle, add a parallel section showing the hotfix branch and its re-entry to staging.
- Post-launch monitoring — extend the prod section to show the on-call window and when the team can consider the release stable.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
gantt
title Software Release Timeline
dateFormat YYYY-MM-DD
section Development
Feature development :dev1, 2026-07-01, 7d
Code review & QA :dev2, after dev1, 3d
Release candidate :crit, dev3, after dev2, 2d
section Staging
Deploy to staging :stage1, after dev3, 1d
Smoke & regression :stage2, after stage1, 2d
Sign-off :stage3, after stage2, 1d
section Production
Deploy to prod :crit, prod1, after stage3, 1d
Monitor & hotfix :active, prod2, after prod1, 3d
Release notes & comms :prod3, after prod1, 2d
Frequently asked questions
- What should a release timeline diagram show?
- A Gantt chart for releases shows the critical path from the development freeze to when the code stabilizes in production: feature lock, QA gates, staging deployment, production rollout, and the post-launch monitoring window. It makes handoff points and overlap visible — which teams can work in parallel (dev and staging for different features), which are blocking (staging sign-off before prod), and how long to keep engineers on call.
- How do I adapt this for my release cadence — weekly sprints, monthly releases, or continuous deployment?
- Change the date ranges to match your cycle — weekly releases compress each section to days, monthly releases spread them out, and continuous deployment might collapse staging into a single gate. The structure stays the same: dev freeze → QA → staging → production → monitor. If you ship multiple features in one release, add parallel dev/stage/prod rows per feature and stack them.
- What do I do if QA fails during staging — do I restart from dev?
- Add a branch in your diagram: after smoke tests, draw a decision diamond for 'Critical bug?'. If yes, loop back to dev (one-line fix cycle) or even just reverify in staging (no dev rework). If no, proceed to sign-off. This makes the risk visible — critical bugs add 5–7 days, and your team knows to plan for retests.
- Can I use this diagram in GitHub Project boards or Jira?
- Yes. The Mermaid Gantt renders in GitHub, Jira, and most modern docs platforms. Copy the code block into a ```mermaid fence. For tighter sync with your task tracker, add ticket numbers as labels (e.g., 'Feature dev [#PROJ-42]') and link the rendered diagram to your epic or release plan.