Sprint plan (Gantt)
Two-week sprint with design, build, and QA.
A two-week sprint has a shape: discovery and design up front, parallel API and frontend work in the middle, and a QA-plus-release crunch at the end. This Gantt chart makes that shape visible — including the dependencies that actually cause sprints to slip, like frontend work that can't start until UI design lands, and QA that can't start until the frontend does.
Because Mermaid Gantt tasks chain with after references rather than
hard-coded dates, the template doubles as a reusable sprint skeleton: change
the first task's start date and the rest of the plan reflows. That makes it
practical to keep in a sprint kickoff doc or planning issue, where heavyweight
project tools rarely get updated.
When to use this template
- Sprint kickoff — agree as a team on sequencing and handoffs before work starts, especially where design, backend, and frontend depend on each other.
- Capacity conversations — when someone asks to add scope, the chart shows exactly which downstream bars move and whether QA still fits in the timebox.
- Stakeholder updates — a one-screen timeline answers "when does this ship?" without granting anyone access to your issue tracker.
How to adapt it
Replace the task names with your sprint's actual work items and set the first date to your sprint start. Useful extensions:
- Add
excludes weekendsunderdateFormatso durations count working days only. - Mark the critical path with the
crittag (:crit, b1, after a1, 4d) to highlight tasks that can't slip. - Add a milestone for the release (
Release :milestone, after c1, 0d) so the ship date reads as a point, not a bar.
If editing the syntax feels fiddly, adjust bars and dates in the visual editor — it regenerates clean Mermaid code that you can paste back into your planning doc.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
gantt
title Two-week sprint
dateFormat YYYY-MM-DD
section Design
Discovery + spec :a1, 2026-06-08, 2d
UI design :a2, after a1, 2d
section Build
API endpoints :b1, after a1, 4d
Frontend :b2, after a2, 4d
section Ship
QA + bug fixes :c1, after b2, 2d
Release + monitor :c2, after c1, 1d
Frequently asked questions
- How do I make a Gantt chart in Mermaid?
- Start with the `gantt` keyword, set a `dateFormat` (here `YYYY-MM-DD`), and group tasks under `section` headings. Each task line is a name followed by a colon, an id, a start (an explicit date or `after someId`), and a duration like `2d`. Mermaid computes the bars and the timeline axis from those values automatically.
- How do task dependencies work in Mermaid Gantt charts?
- Give each task an id (`a1`, `b2`) and start dependent tasks with `after thatId` instead of a date. In this template only the first task has a fixed date — everything else chains off it, so shifting the sprint start date by editing one line reflows the entire plan. A task can also depend on multiple ids: `after a1 b1`.
- Can a Mermaid Gantt chart skip weekends?
- Yes. Add an `excludes weekends` line below `dateFormat` and Mermaid stretches task bars across Saturday and Sunday without counting them as working days. You can also exclude specific dates (`excludes 2026-06-19`) for holidays. For a real sprint plan this is usually worth adding, since a 4-day task started on Thursday otherwise looks like it finishes on Sunday.
- Are Gantt charts useful for agile sprints?
- For tracking, a board beats a Gantt — but for planning a timeboxed sprint, the chart answers questions a board can't: whether design finishes before build needs it, where QA gets squeezed, and which handoffs are on the critical path. Because this one is plain text, it lives in the sprint doc and takes seconds to update, unlike heavyweight project tools.