Short answer: To modernize capacity planning in Jira, retire the standalone spreadsheet and keep availability, days off, allocation, and past velocity next to the backlog, so the capacity number is refreshed before every commitment. That removes the copy-and-paste step where most planning errors start.

On planning day, the scrum master has the backlog in one window and a capacity workbook in another. Someone’s training week is on a shared calendar, a part-time detail is noted in an email, and the holiday is in the agency’s HR system. The workbook is only as current as the last person who touched it.

Why do spreadsheets break down for government sprint planning?

Spreadsheets fail quietly. They are versioned by filename (“capacity_v7_FINAL”), owned by whoever built them, and disconnected from the backlog they are supposed to constrain. In a public-sector setting three things make this worse:

• Shared and detailed staff. People split across programs make simple headcount math wrong.
• Fixed calendars. Federal holidays, fiscal-year close, and mandatory training are known months ahead, yet often missed.
• Fewer people, same mission. When staffing is cut or budgets are flat, a 10% capacity error is no longer absorbed by slack. It becomes a missed commitment you have to explain up the chain.

Moving to Atlassian Cloud, including Atlassian Government Cloud (AGC) for agencies that require it, is a natural moment to stop treating capacity as a side document and make it part of the planning system itself.

How do you move capacity planning into Jira?

You do not need a big-bang migration. Follow these five steps over one or two sprints.

1. Inventory what the spreadsheet actually calculates. List every column: working days, holidays, PTO, allocation percentage, focus factor. Anything not on the list is a hidden assumption to surface.
2. Define one capacity formula. Available person-days = working days minus holidays, days off, and training, multiplied by the allocation percentage. Write it down once so every team uses the same definition.
3. Pull velocity from Jira history. Use the last three completed sprints, not the best one. Divide points delivered by person-days that were available in each sprint to get points per person-day.
4. Plan days off before the sprint starts. Collect known absences at sprint-planning time, not mid-sprint, and record them where the team plans.
5. Run the two systems in parallel once, then retire the spreadsheet. Compare the outputs. If they differ, the difference is usually an assumption from step 1 that nobody wrote down.

What does the math look like in practice?

Here is an illustrative example (not customer data) for a seven-person team planning a two-week sprint, October 5 to 16, which includes the October 12 federal holiday.

Recent history: the team delivered 32, 36, and 34 points in its last three sprints, with 58, 62, and 60 person-days available. That is 102 points over 180 person-days, or about 0.57 points per person-day.

• Naive spreadsheet count: 7 people × 10 days = 70 person-days, which implies about 40 points.
• Subtract the holiday for all seven: 70 − 7 = 63.
• Subtract one person’s 3-day training: 63 − 3 = 60.
• One person is allocated 50% to another program, so 4.5 of their 9 remaining days come off: 60 − 4.5 = 55.5.
• One person has 2 days of leave: 55.5 − 2 = 53.5 person-days.
• 53.5 × 0.57 ≈ 30 points.

The honest commitment is about 30 points, not 40. Committing to 40 would have set up a 25% miss before the sprint began, and the miss would have looked like a performance problem instead of a planning problem.

Why does doing this in one tool make it repeatable?

The formula above is easy. Doing it accurately every two weeks, for every team, with changing rosters, is what fails. When capacity lives inside the Jira backlog, the inputs (past velocity, days off, allocation) sit on the same screen as the work being committed, and the number updates as you adjust the plan.

Sprint planning with Capacity Planning for Jira is built for this. It lets you plan sprints and team capacity on one screen using past velocity, days off, and allocation before you commit, inside the Jira backlog. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. It also leaves a simple planning record of who was allocated, which days off were subtracted, and why the team committed to N points, which is useful when a reviewer asks how a commitment was reached. It records planning decisions; it is not a compliance product.

A practical next step: the 90-minute readiness check

Before changing any tooling, spend 90 minutes with your scrum master and one developer. Take your last sprint, recompute capacity using the formula above, and compare it with what the spreadsheet said. If the gap exceeds 10%, that gap is your business case for moving the calculation into Jira.

FAQ

Can Jira calculate sprint capacity without a spreadsheet?

Native Jira shows velocity and sprint contents but does not model individual availability. A Marketplace app that adds days off, allocation, and velocity to the backlog view fills that gap.

How many sprints of history do we need?

Three completed sprints is a workable minimum for a stable team. With fewer, treat the estimate as provisional and adjust after each sprint.

Does this replace our reporting to leadership?

No. It makes the numbers you already report (committed versus delivered) easier to defend, because the capacity assumptions behind each commitment are written down.

Try it: Install free on the Atlassian Marketplace · Help docs