Short answer: convert every person into available person-days for the sprint (working days minus holidays and leave, multiplied by the share of their time actually assigned to your team), add them up, then multiply by your team’s historical points per available person-day. Headcount is the wrong starting number when half the team is part-time or detailed elsewhere.

Picture a state licensing agency with seven names on the team roster. On paper that is seven people. In practice, two work half-time on the project, one is detailed to another program two days a week, and one is a security reviewer who gives the team a day a week at best. Plan against seven full-time people and the sprint is over-committed before it starts.

Why does headcount mislead government teams?

Public-sector rosters rarely match real availability. Staff are detailed across programs, shared with operations, or split between a legacy system and its replacement. Hiring freezes and workforce reductions make this more common: with fewer people covering the same mission, every shared resource is stretched across more commitments. When staff are cut, knowing real capacity before committing matters more, not less.

The cost shows up later. A missed sprint goal becomes a status-report explanation, and a pattern of misses becomes a credibility problem with the oversight chain that funds the work.

How do you calculate sprint capacity step by step?

1. Count working days in the sprint. Start with the calendar, then remove holidays that fall inside it.
2. Subtract each person’s known days off. Planned leave, training, and mandatory agency events.
3. Apply each person’s allocation. Allocation is the share of their time assigned to this team: 100%, 50%, 20%, or 3 of 5 days for someone detailed elsewhere two days a week.
4. Sum the result into available person-days. This is the team’s real supply of time.
5. Convert with past velocity. Divide recent completed points by the person-days available in those sprints, then apply that ratio to this sprint.

Step 5 matters. Velocity already reflects meetings, support interruptions, and rework, so you do not subtract an extra overhead factor on top. Doing so double-counts it.

What does a worked example look like?

Take a two-week sprint from November 2 to November 13, 2026. That is 10 working days, and Veterans Day (November 11) removes one, leaving 9. The numbers below are illustrative.

• Ana, developer, 100%: 9 days = 9.0
• Ben, developer, 100%, one day of leave: 8 days = 8.0
• Chen, QA, 100%: 9 days = 9.0
• Dara, developer, 50%: 9 × 0.5 = 4.5
• Eli, business analyst, 50%: 9 × 0.5 = 4.5
• Farah, detailed elsewhere two days a week (60% here): 9 × 0.6 = 5.4
• Gus, security reviewer, 20%: 9 × 0.2 = 1.8

Total: 42.2 available person-days, against 63 if all seven were full-time for 9 days.

Now past velocity. In the last three sprints the team finished 38, 34, and 41 points with 44, 40, and 46 available person-days. That is 0.86, 0.85, and 0.89 points per person-day, averaging about 0.87. Applied to 42.2 days, the forecast is roughly 36.6 points, so the team commits to about 36.

Plan from the roster instead: 63 days × 0.87 gives about 55 points. That is roughly 18 points, or about 50%, more than the team can deliver. Same people, same history; the only difference is whether allocation and days off were counted.

What pitfalls should you watch for?

• Treating a detail as a rumor. If someone is detailed elsewhere, get the allocation agreed with their other supervisor and write it down.
• Counting the same person twice. A shared specialist at 20% on three teams cannot be 100% on any of them.
• Mixing velocity eras. Use ratios from sprints with a similar team makeup, or the average will mislead.
• Calculating once and never revisiting. Recheck at sprint planning, since leave and details change week to week.

Why does a record of capacity decisions matter?

Buyers and oversight bodies increasingly want to see what happened, who acted, what changed, and what evidence supported the decision. A capacity calculation that lives in a personal spreadsheet cannot answer those questions a year later. A record showing who was allocated, which days off were subtracted, and why the team committed to 36 points can. This is a documentation habit, not a compliance product: it makes your planning decisions easy to explain and review.

How does doing this in Jira make it repeatable?

The method above works in a spreadsheet, but it breaks down at sprint two, when someone changes a cell or the file forks. The other cost is switching: capacity in one place, the backlog in another, and the commitment negotiated between them. As agencies move work onto Atlassian Cloud and Atlassian Government Cloud (AGC), it makes sense to bring this calculation along.

Sprint planning with Capacity Planning for Jira puts sprint planning and team capacity on one screen inside the Jira backlog. It uses past velocity, days off, and allocation to show what the team can take on before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. Allocation and days off are entered once and reused each sprint, so the calculation above becomes a routine step instead of an afternoon of spreadsheet work.

FAQ

How do you calculate capacity for a part-time team member?
Multiply their available working days (after holidays and leave) by their allocation percentage. A person at 50% with 9 available days contributes 4.5 person-days.

Should detailed staff be counted in sprint capacity?
Only for the share of time formally assigned to your team. If a person is detailed elsewhere two days a week, count three of five days, and confirm that arrangement in writing.

Do I need to subtract meetings and overhead separately?
Not if you convert using your own historical points per available person-day, because velocity already includes that overhead. Subtracting it again double-counts it.

A quick readiness check: before your next planning session, list every person on the roster with their allocation and known days off for the sprint. If you cannot fill that list in five minutes, capacity is not yet visible to the team.

Try it: Install free on the Atlassian Marketplace · Read the help docs