How to do sprint capacity planning in Jira Cloud without spreadsheets

Spreadsheets become stale immediately

The moment sprint dates, estimates, or assignees change in Jira, the copy outside Jira is already drifting away from the source of truth.

Confidence drops when inputs are incomplete

Unestimated or unassigned issues are easy to miss in manual planning, so the team walks into sprint planning without a clear confidence signal.

Upcoming sprints are hard to compare quickly

Teams often scan each sprint separately instead of seeing demand vs capacity across the next few sprints in one consistent view.

What the team should be able to answer quickly

Before a sprint slips, the team should be able to answer a few simple questions without opening a spreadsheet:

• Are we overbooked, healthy, or tight?
• Which upcoming sprint looks riskiest?
• Are missing estimates or missing assignees weakening the signal?
• Is the board using story points, hours, or falling back to counts?

Unestimated work

If a meaningful part of the sprint has no estimate, demand looks artificially low and the team overstates available capacity.

Unassigned work

Capacity becomes hard to derive when the sprint backlog is not attached to real people or a real team shape.

Board estimation is unclear

If the Jira board is not consistently configured for story points or a time-based estimate field, teams end up planning on counts or guesses.

Availability assumptions live outside Jira

When team capacity defaults and exceptions are only remembered verbally or in a spreadsheet, planning signal becomes hard to explain and audit.

What to look for in the view

• Current sprint signal: a fast read on whether the active sprint looks healthy, tight, or overbooked.
• Health and utilization: enough to understand whether the plan is realistic before the sprint starts drifting.
• Next 3 sprint canvas: a compact view of demand, capacity, delta, and quality flags across upcoming sprints.
• Settings summary: which board is selected and what capacity assumptions the page is using.

That combination is usually enough for sprint planning, backlog refinement, and the last review before a sprint is committed.

Capacity page inside Jira project navigation

The app adds a Capacity page directly to the Jira project, so the team stays in the same workspace it already uses for planning and delivery.

Demand vs capacity across the next 3 sprints

Select a Scrum board once and Sprint Canvas loads the active sprint plus the next two future sprints for a compact planning view.

Explainable quality signals

Instead of hiding uncertainty, Sprint Canvas flags unestimated or unassigned work, board-estimation issues, and no-signal situations directly in the page.

Story points or time-based estimation

The app reads the board configuration and surfaces the unit the board already uses, whether that is story points or time converted into hours for display.

Weekly capacity defaults with per-person overrides

Set a default weekly capacity once, then adjust only where a specific person needs a different assumption for the sprint horizon.

Minimal data surface

Built on Atlassian Forge with no external services, Sprint Canvas stores only the small project-level settings it needs for calculations.