The short answer: Modernizing capacity planning means retiring the standalone spreadsheet and calculating sprint capacity where the work actually lives — inside the Jira backlog — so every commitment reflects who is truly available, not a figure copied from last quarter. For agencies moving to Atlassian Cloud, it is one of the highest-leverage steps toward predictable, auditable delivery.

Walk into almost any government agile team and you will find a capacity spreadsheet. It has a tab for team members, a column for planned time off, a hard-coded velocity number near the top, and a formula nobody has touched since the last scrum master rotated off. It works — until it doesn’t. Someone gets detailed to another program, a federal holiday lands mid-sprint, and the sprint commitment quietly becomes fiction. The team overcommits, misses the sprint goal, and the next status report up the chain has to explain a slip that was baked in on day one.

That gap between the spreadsheet and reality is the real cost of legacy capacity planning, and it is getting more expensive. With flat budgets and workforce reductions across federal, state, and local agencies, teams are being asked to deliver the same mission with fewer people. When staff are cut, knowing your true capacity before you commit matters more, not less — a five-point overcommitment on a six-person team stings far more than it did on a ten-person team.

Why is the spreadsheet the bottleneck?

The problem is not that spreadsheets are bad at math. It is that they live away from the work. Your backlog is in Jira; your availability is in a file on someone’s drive. Every sprint, a human has to reconcile the two by hand, and every manual reconciliation is a chance for the numbers to drift. The spreadsheet also has no memory of why a decision was made. When an auditor, an IG reviewer, or a new program manager asks “why did the team commit to 32 points that sprint?”, the answer lives in someone’s head, not in a record.

Modernization — the same shift moving agencies from Data Center to Atlassian Cloud and Atlassian Government Cloud (AGC) — is the chance to fix this. Doing capacity planning inside Jira, on the platform where the work already lives, turns a fragile manual step into a repeatable one.

How do you move capacity planning off the spreadsheet?

You do not need a six-month project. Work through five steps:

1. Inventory what the spreadsheet actually does. List every input: team roster, sprint length, planned time off, meeting overhead, and the velocity assumption. Most spreadsheets quietly bundle these together. Naming them is the first step to standardizing them.
2. Move the availability math next to the backlog. Capacity is only useful at the moment you choose what to pull into the sprint. If you have to switch tools to see it, you will skip it under deadline pressure. Put the number on the same screen as the issues.
3. Standardize one capacity formula. Decide, as a team, how you convert people and days into a commitment ceiling — and use it every sprint. Consistency is what makes the number trustworthy over time and comparable across sprints.
4. Make days-off and allocation first-class inputs. Federal holidays, PTO, training days, and partial allocation (the developer who is “half on your team”) should be explicit subtractions, not a fudge factor. This is also what creates a clean record of why capacity was what it was.
5. Close the loop with past velocity. Use what the team actually delivered in recent sprints as the reality check on what the raw availability math suggests. Availability tells you the ceiling; velocity tells you the realistic floor.

What does the math actually look like?

Here is a worked example. Suppose a state benefits-modernization team has six developers and runs two-week sprints (10 working days).

• Start with raw capacity: 6 people × 10 days = 60 person-days.
• One federal holiday falls in the sprint: −6 person-days → 54.
• Two developers each take one PTO day: −2 → 52.
• One developer is only 50% allocated to this team: −5 → 47.
• Reserve 15% for ceremonies, code review, and support: −7 → 40 person-days of real, plannable capacity.

If the team’s recent velocity averages about one story point per usable person-day, a commitment near 40 points is grounded. The unmodernized version of this team started from “we did 55 last sprint” and pulled in 52 — then lost a third of its available days to a holiday and an allocation it never subtracted. Same team, very different sprint outcome.

Doing it once, on one screen

The reason this discipline usually erodes is friction: it lives in a second tool, so it gets skipped. Sprint planning with Capacity Planning for Jira removes that friction by putting the whole calculation on one screen inside the Jira backlog. You see each team member’s availability, subtract days off and allocation, factor in past velocity, and watch your capacity ceiling update as you drag issues into the sprint — before you commit, not after. Because it runs on the Atlassian Cloud platform, it is Cloud Fortified and sits on Atlassian’s SOC 2 Type II / ISO 27001 infrastructure — a fit for teams standardizing on Cloud and AGC.

There is an accountability payoff too. When capacity is planned in the tool, you naturally produce a record of who was allocated, which days were subtracted, and why the team committed to N points. That decision trail — proof of what was planned and why — is exactly what leadership and reviewers increasingly want to see, without anyone maintaining a separate audit spreadsheet.

FAQ

Do we have to abandon our spreadsheet on day one?
No. Run both for a sprint or two. Plan capacity in Jira, keep the spreadsheet as a shadow check, and once the numbers line up and the team trusts the on-screen figure, retire the file.

Will this work if our team estimates in hours instead of story points?
Yes. The same availability math applies whether your commitment ceiling is expressed in person-days, hours, or points. Standardize on whichever unit your team already estimates in.

Is capacity planning in Jira a compliance or security certification?
No. The app records your planning decisions and runs on Atlassian’s certified Cloud platform (Cloud Fortified), but it does not itself provide a compliance certification. Its value for accountability is the documented decision trail it produces.

Get started

Retiring the capacity spreadsheet is a modernization win you can land in one fiscal quarter. A simple 90-day plan: in sprints 1–2, run the tool alongside your spreadsheet; in sprints 3–4, make the on-screen number the source of truth; from sprint 5 onward, drop the spreadsheet and review capacity-versus-actuals as a standing agenda item.

---

Try it: Install free · Help docs