Modernizing capacity planning means retiring the standalone spreadsheet and calculating sprint capacity inside Jira itself — where past velocity, days off, and each person’s allocation sit on the same screen as the backlog. The plan gets made where the work lives, instead of being reconciled against it after the fact.

Picture a state licensing-modernization team the week before Sprint 19. The scrum master opens Capacity_FY26_Q4_v14_FINAL(2).xlsx, emails two contractors to confirm their hours, discovers the version on the shared drive doesn’t match the one attached to last week’s status email, and spends Thursday afternoon re-keying numbers into Jira by hand. Nothing about that is agile — and with hiring freezes leaving many public-sector teams running the same mission with fewer people, an afternoon of reconciliation is an afternoon the team no longer has to spare.

Why do spreadsheets break down for government capacity planning?

Spreadsheets fail public-sector teams in ways that matter more in government than anywhere else:

• They drift from the backlog. The spreadsheet says the team has 62 hours; the Jira sprint quietly fills up with 80 hours of committed work. Nobody notices until the mid-sprint scramble.
• They have no memory. When a program office asks “why did the team commit to 24 points in March?”, the answer lives in a file version someone overwrote in April. There’s no durable record of who was allocated, which days off were subtracted, or why the number was what it was.
• They don’t scale past one team. A PMO overseeing four teams gets four differently-formatted files, each with its own formulas and its own bugs.
• They’re a modernization dead end. Agencies moving their work management to Atlassian Cloud — including Atlassian Government Cloud (AGC) — are consolidating tooling, not adding side systems that live outside it.

How do you move capacity planning from a spreadsheet into Jira?

A practical four-step migration most teams can complete inside a single quarter:

1. Inventory what the spreadsheet actually does. Most capacity spreadsheets compute three things: available days per person, an allocation percentage per person, and a total the team compares against velocity. List those inputs — they are what your Jira-based view must capture, and anything else is probably cruft you can drop.
2. Establish a velocity baseline in Jira. Pull the last three to five completed sprints. If your history is polluted by scope changes, mark those sprints and use the cleaner ones. This replaces the spreadsheet’s “gut feel” target with a number you can defend up the chain.
3. Record availability where planning happens. Federal holidays, approved leave, mandatory training, and partial allocations (the analyst who is 50% on another program) go into the planning view itself — not a separate file. This is also where the decision trail comes from: months later, the record still shows exactly what was subtracted and why the team committed to the number it did.
4. Run two sprints in parallel, then cut over. Keep the spreadsheet for two sprints as a shadow check. When the Jira-based plan and the spreadsheet agree — or the Jira plan proves more accurate — archive the file and announce the cutover. A clean end date prevents the spreadsheet from lingering as an unofficial second source of truth.

A worked example: the licensing team’s first spreadsheet-free sprint

That licensing team has six people on a two-week, ten-working-day sprint, with a three-sprint average velocity of 30 points:

• Two developers, full-time and fully allocated: 20 available days
• One developer taking 3 days of leave: 7 available days
• One tester at 80% allocation (20% on a legacy support contract): 8 effective days
• One analyst at 50% across two programs: 5 effective days
• One contractor with a 1-day mandatory security training: 9 available days

That’s 49 effective person-days against 60 nominal — the team is at roughly 82% of full capacity. Scaling the 30-point velocity by 0.82 gives a defensible commitment of about 24–25 points. In the old spreadsheet workflow, that arithmetic took an afternoon and was stale by Monday. Calculated in the planning view, it takes minutes and updates the moment someone’s leave is approved.

What changes when it all lives on one screen in Jira?

Doing this inside Jira makes the discipline repeatable instead of heroic. With Sprint Planning with Capacity Planning for Jira, past velocity, days off, and per-person allocation appear directly in the backlog view, and the capacity total updates as you drag work into the sprint — so the team sees over-commitment before it commits, not at the retrospective. Because the plan is recorded where the work is tracked, every sprint leaves a trail of what was assumed and what was decided — the kind of documentation government stakeholders increasingly expect. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

FAQ

Do we have to abandon our spreadsheet immediately?
No. Run it in parallel for two sprints as a shadow check, then set a firm cutover date. The parallel run builds confidence and catches any inputs your team tracks that you haven’t yet moved into Jira.

What if our velocity history is unreliable?
Use the last three to five sprints and exclude clear outliers (a sprint gutted by a shutdown or an emergency tasking). An imperfect baseline you refine each sprint beats a spreadsheet estimate you can’t audit.

Does this work for teams on Atlassian Government Cloud?
The approach — velocity baseline, availability, allocation, one planning view — applies wherever your Jira backlog lives. Check the Marketplace listing for current hosting availability for your environment.

Try it: Install Sprint Planning with Capacity Planning for Jira free from the Atlassian Marketplace · Help docs — a practical first step: run the four-step migration above as your next quarter’s improvement goal, starting with the spreadsheet inventory this week.