Short answer: To align sprint planning with capacity planning, work out your team’s available person-days first (after holidays, leave, training and part-time allocation), convert them to story points using recent velocity per person-day, and only then pull work into the sprint. Capacity sets the ceiling; the backlog fills it.

Picture the sprint review where a program manager has to explain, again, why only 22 of 34 committed points were finished. Nobody was slacking. Two people were on a detail, a holiday landed mid-sprint, and the plan assumed a full team anyway. With fewer staff and fixed budgets, agencies cannot absorb that kind of miss quarter after quarter.

Why do sprint plans and capacity plans drift apart in government?

In most agencies they live in different places. Sprint planning happens in the Jira backlog; capacity lives in a spreadsheet, an email thread, or a scrum master’s head. When staff are cut or reassigned, the spreadsheet is the first thing to go stale, and the sprint commitment quietly keeps assuming last quarter’s team.

Public-sector teams also have constraints that make the gap wider: federal and state holidays, mandatory training, shared specialists split across programs, and fiscal-year deadlines that turn a missed sprint into a missed milestone. “Fewer people, same mission” only works when you know, before you commit, how much work the remaining people can really absorb.

How do you align sprint planning with capacity planning?

Use this sequence every sprint. It takes about fifteen minutes once it becomes routine.

1. Start with working days, not calendar days. Count the working days in the sprint and remove public holidays before anything else.
2. Apply allocation per person. A developer who gives your program 50% of their time contributes half their working days, not all of them.
3. Subtract known days off. Leave, training, court or jury duty, and planned travel come out next. Ask for these before planning starts, not during it.
4. Convert days to points using real history. Divide recent completed points by the person-days available in those sprints. Use the last three sprints, not your best one.
5. Commit to the result, then hold a buffer. Pull stories until you reach the capacity-based number, and keep a small reserve (many teams use 10%) for unplanned work.

What does the calculation look like with real numbers?

This is an illustrative example, not a customer case. A six-person team runs a 10-working-day sprint, and one of those days is a federal holiday, leaving 9 working days.

• Four people are full-time: 4 × 9 = 36 person-days.
• Two people are 50% allocated: 2 × 4.5 = 9 person-days.
• Gross capacity: 45 person-days.
• Leave of 4 days and training of 3 days: minus 7, leaving 38 available person-days.

Over the last three sprints the team finished 90 points across 120 available person-days, or 0.75 points per person-day. Planned capacity is therefore 38 × 0.75 = 28.5, so the team commits to about 28 points. A plan built on the team’s headline average of 30 points would have overcommitted by roughly 7%, which is exactly the margin that turns a clean sprint into a carry-over.

What should the PMO document each sprint?

Leadership increasingly wants to see what happened, who acted, what changed and what evidence supports a decision. Sprint planning is a small but real part of that record. A short, consistent note per sprint covers it: who was allocated and at what percentage, which days off were subtracted, what velocity figure was used, and why the team committed to N points. This is decision-trail practice, not a compliance program, but it answers the question “why did you commit to that?” months later without anyone reconstructing it from memory.

How does doing this in one tool inside Jira make it repeatable?

The method above is simple; the failure point is upkeep. Every spreadsheet handoff is a chance for an outdated number. Moving the calculation into the Jira backlog, the same place the stories are ranked, removes the copy-and-paste step and keeps capacity and commitment visible together. It is also a natural part of modernizing onto Atlassian Cloud, including Atlassian Government Cloud (AGC) for agencies moving there, rather than carrying side spreadsheets along.

Sprint planning with Capacity Planning for Jira does this on one screen: it uses past velocity, days off and allocation so you can see capacity against the sprint before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform. It records planning decisions; it is not a compliance product.

A 30-day way to start

Pick one team. In sprint one, run the five steps in a spreadsheet and compare the plan to the actual outcome. In sprint two, bring days-off collection forward to the day before planning. By sprint three, you will have a velocity-per-person-day figure you trust, and a clear case for moving the routine into Jira.

FAQ

How often should we recalculate capacity?
Every sprint. Allocation, leave and staffing change faster than most plans assume, especially during workforce reductions or reassignments.

Should part-time and detailed staff be counted?
Yes, at their actual allocation percentage. Counting them as full-time is the most common source of overcommitment.

Is velocity enough on its own?
Velocity describes what a team delivered under past conditions. Without adjusting for this sprint’s available days, it overstates or understates what is realistic.

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