About this template
Most teams plan sprints in Jira tickets and a backlog, then lose track of when each piece is actually shipping. A Gantt view of a single sprint surfaces the real schedule: when design hands off to engineering, when each story is in review, when QA picks it up, when the demo is. This 2-week template can be cloned for every sprint or used to plan a longer release as a chain of sprints.
How a 2-week sprint breaks down
Sprint kickoff
Sprint planning meeting: review backlog, story estimates, capacity vs. velocity, sprint goal. Confirm everyone has their stories assigned. End with a single-sentence sprint goal that anyone on the team can recite.
- Backlog refinement
- Story point estimation
- Capacity vs. velocity check
- Story assignment
- Sprint goal
Days 2–4 — Design and start
Designers wrap any remaining specs. Engineers start the largest stories first (move the risk forward in the sprint). Daily standup at the same time every day — 15 minutes, three questions per person.
- Daily standup
- Designer hands off specs
- Engineers start largest stories
- PR template and review SLAs confirmed
Days 5–8 — Build
Heads-down development. Code reviews happen continuously (target: PR open less than 24 hours before first review). Mid-sprint check-in on day 7 — flag any story at risk of slipping.
- Daily standup
- Code reviews (24h SLA)
- Mid-sprint check-in (day 7)
- Re-scope at-risk stories
Days 9–11 — QA and merge
Stories complete and ready for QA. Bug fixes from QA loop back to developers. By end of day 11, every shippable story is merged. Anything that did not land moves back to the backlog.
- QA pass on completed stories
- Bug fix loop
- Merge to main
- Update release notes
Days 12–14 — Demo and retro
Day 12: deploy to staging, smoke test. Day 13: sprint demo to stakeholders — every story owner presents their work. Day 14: retrospective — what went well, what slowed us down, what to try next sprint. Schedule the next sprint kickoff.
- Deploy to staging
- Smoke tests
- Sprint demo
- Retrospective
- Next sprint kickoff
Tips from teams running smooth sprints
- Start the largest story first. Move risk forward in the sprint, not later.
- Open every PR within 24 hours of the work being ready. PRs sitting unopened are silent delays.
- Hold the mid-sprint check-in on day 7. Stories at risk on day 7 are still salvageable; on day 12 they are not.
- End every retrospective with one concrete change for next sprint. Lists of 15 ideas produce zero changes.
- Run the demo even if half the stories did not land. Showing partial work creates pressure to ship.
Frequently asked questions
Is Gantt useful for agile sprints?
Yes — for a single sprint view, it makes story sequencing and handoffs visible in a way a Kanban board does not.
Should I do this for every sprint?
A single sprint Gantt is most useful for the first 3–5 sprints of a new team, or for any sprint with cross-functional dependencies.
Can I chain multiple sprints into a release plan?
Yes. Open this template, then add 2–3 more 2-week blocks for a release-level view.