How do you plan capacity for a hybrid government team? Count available days per person (not headcount), subtract holidays, leave, and on-site obligations, apply each person’s allocation, then convert the result to points using your team’s recent velocity per available day. Do this before committing to a sprint goal.

Your sprint plan assumes seven people. On Tuesday, three are on-site for a mandated in-person day, one is split with another program, and one is on leave. “Seven people” is no longer a plan. For agencies running hybrid or distributed teams with fewer staff than last year, capacity is the number that decides whether a commitment holds.

Why does hybrid work make capacity harder to see?

In a co-located team, absences are visible: you notice the empty desk. In a hybrid or distributed team, availability hides in calendars, time zones, and other programs’ schedules. Government teams add their own layers: required on-site days, security or records training, shared-service staff detailed from other offices, and contractors whose hours follow a task order.

The planning risk is simple. Teams commit based on headcount and last sprint’s velocity, and a week later the gap between promised and delivered work becomes a status-report problem. With workforce reductions and flat budgets, “fewer people, same mission” makes that gap more expensive, because there is no slack left to absorb a bad estimate.

How do you calculate sprint capacity in a distributed team?

Use a five-step method that works the same way every sprint:

1. Start with working days. Multiply sprint length by team size. A 10-day sprint with six people gives 60 person-days.
2. Remove non-working days. Subtract federal holidays and each person’s approved leave, using the same calendar for everyone.
3. Remove fixed obligations. Mandatory training, all-hands, and on-site days that are not sprint work come out next.
4. Apply allocation. If someone is 50% on this team and 50% on another program, count half of their remaining days.
5. Convert with real history. Divide recent completed points by recent available days to get points per available day, then multiply by this sprint’s available days.

What should you account for that is specific to hybrid teams?

• Overlap hours. If reviewers sit three time zones from developers, work that needs a handoff takes longer. Plan fewer cross-zone dependencies per sprint rather than assuming they cost nothing.
• On-site days. Travel and in-person requirements reduce focused time. Treat them as a deduction, not a rounding error.
• Detailed and shared staff. Record the actual percentage allocated to your sprint, agreed with their other manager, instead of a verbal “mostly ours.”
• Contractor hours. Capacity follows the hours in the task order, not the number of names on the roster.

What does a worked example look like?

This is an illustrative example, not data from any agency. A six-person team runs a 10-day sprint that contains one federal holiday. After the holiday, each person has 9 days.

Person	Days after holiday	Leave	Allocation	Available days
A	9	2	100%	7.0
B	9	0	100%	9.0
C	9	1	100%	8.0
D	9	0	50%	4.5
E	9	1	50%	4.0
F	9	0	80%	7.2

Total available: 39.7 days, against a naive 60. Suppose the last three sprints delivered 34, 38, and 36 points on 41, 44, and 40 available days. That is 108 points over 125 days, or about 0.86 points per available day. Multiply by 39.7 and the forecast is roughly 34 points. A team that simply repeated last sprint’s 36 would be over-committed before the first standup, and a team that assumed a full six-person roster would be off by far more.

How does this support a record of planning decisions?

Leadership increasingly asks teams to show what happened, who acted, what changed, and what evidence supported a decision. A capacity calculation that is written down, with allocations, days off, and the velocity basis, is that kind of evidence for the sprint commitment: it explains why the team committed to 34 points and not 40. It is a planning record, not a compliance program, and it is worth keeping consistent across sprints.

How does one tool inside Jira make this repeatable?

Rebuilding this in a spreadsheet each sprint is where errors creep in: a stale leave tab, an allocation nobody updated, a velocity figure copied from memory. 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, so you see the capacity picture before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform, which suits agencies moving their delivery tooling to Atlassian Cloud. Setup steps are in the help docs.

A 30-day starting point

Pick one team. For the next sprint, list every person’s allocation percentage, leave, and fixed obligations on one page. Calculate points per available day from your last three sprints. Commit to the forecast, and compare it with the result at the retrospective. After two sprints you will know how much your hybrid arrangement really costs.

FAQ

Do time zones change the capacity number?
Not the day count, but they change how much work can flow through handoffs. Reduce the number of cross-zone dependencies in a sprint instead of subtracting an arbitrary percentage.

How should we count a person detailed to us part-time?
Use the allocation agreed with their other manager, apply it to their remaining days, and update it when it changes.

Is points per available day reliable with only a few sprints of history?
It is a forecast, not a guarantee. Three sprints give a usable starting range, and it improves as history grows.

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