Short answer: Capacity planning for a hybrid or distributed government team means calculating available person-days per sprint for each person individually — accounting for telework schedules, time-zone overlap, split allocations, holidays, and leave — and then converting that number into a point commitment using your team’s actual historical throughput, not a headcount average.

A program manager at a state licensing modernization office described her sprint planning problem this way: “On paper I have six people. In practice I have two in the office Tuesday through Thursday, one fully remote in a county three hours away, two contractors who log in from a different time zone, and one analyst who belongs half to us and half to the legacy support queue. When the team says they can do 30 points, I have no idea whether that’s true.”

That is not a scrum problem. It is an arithmetic problem that nobody is doing. And it has become more consequential, not less: with workforce reductions and flat budgets across FedCiv, DoD, and state and local agencies, the “fewer people, same mission” math means the gap between assumed capacity and real capacity now shows up as a missed milestone rather than a rounding error.

Why hybrid teams break the usual capacity shortcuts

Most teams estimate capacity with a shortcut: headcount times sprint length, minus a rough guess for meetings. That works when everyone is co-located, full-time, and dedicated to one program. Distributed public-sector teams violate all three assumptions at once.

• Availability is per-person, not per-team. A 60% contractor and a full-time GS-13 do not contribute the same number of days, and averaging them hides both.
• Overlap hours are a real constraint. A team spread across three time zones with four hours of daily overlap has less collaborative bandwidth than the same six people in one room — pairing, review, and unblocking all queue up inside that window.
• Telework schedules create uneven weeks. Return-to-office policies that mandate specific in-office days concentrate collaboration into part of the sprint and leave the rest for solo work.
• Split allocation is the norm. Detail assignments, legacy support rotations, and acquisition-support duties routinely take 30–50% of a person without ever showing up in the sprint board.

How do you calculate sprint capacity for a distributed government team?

Use a four-step sequence. It takes about twenty minutes the first time and five minutes every sprint after that.

1. Start from raw person-days. Team size × working days in the sprint. This is the only number you should ever compute as a team-level figure.
2. Subtract per-person unavailability. Federal or state holidays, approved leave, mandatory training, all-hands and town halls, and known court or hearing dates. Do this name by name — the whole point is that the team is not uniform.
3. Apply each person’s allocation percentage. If someone is 50% committed to a support rotation, they contribute half their remaining days. If a new contractor is still ramping, model them at 50–70% for their first two sprints and say so out loud.
4. Convert person-days to points using your own throughput. Take the last three sprints, divide points delivered by person-days actually available in those sprints, and use that ratio. It already contains your team’s real coordination overhead — including the cost of being distributed — so you do not need to invent a separate “focus factor.”

One addition specific to hybrid teams: record your daily overlap window as a planning constraint. If a story needs two people working together and only one of them is inside the overlap window, that story carries schedule risk regardless of how many points it is.

A worked example

A six-person licensing modernization team runs a two-week sprint with 10 working days.

• Raw capacity: 6 people × 10 days = 60 person-days
• State holiday affecting everyone: −6
• Approved leave (one developer 3 days, one analyst 2 days): −5
• Mandatory security awareness training, half a day each: −3
• Two people at 50% on the legacy support rotation: −10
• New contractor ramping at 60% for the sprint: −4

Total deductions: 28. Available capacity: 32 person-days.

Now the conversion. The last three sprints delivered 26, 31, and 24 points — an average of 27 points against an average of 34 available person-days. That is roughly 0.79 points per person-day. So 32 × 0.79 ≈ 25 points.

The team’s instinct was 30 points, because that is what “six people for two weeks” feels like. The arithmetic says 25. The difference — five points, roughly 17% — is exactly the overcommitment that turns into carryover, a yellow status, and an uncomfortable conversation with the steering committee.

Why doing this in one place matters

Every step above is doable in a spreadsheet, and thousands of agency teams do it that way. The failure mode is not accuracy; it is durability. The spreadsheet lives on one person’s drive, drifts out of sync with the Jira backlog, and disappears when that person moves to another program.

This is one of the practical arguments for the broader move to Atlassian Cloud and Atlassian Government Cloud (AGC): planning that happens inside the system of record stays attached to the work. When capacity, days off, allocation percentages, and past velocity sit on the same screen as the backlog you are committing to, the calculation becomes repeatable instead of heroic — and it leaves a record. Anyone reviewing the sprint later can see who was allocated, what was subtracted, and why the team committed to 25 points rather than 30. That is a documentation and decision-trail benefit, which matters in an environment where buyers increasingly expect to be able to show what happened and what informed a decision.

That is the problem DiViM built Sprint planning with Capacity Planning for Jira to solve: plan sprints and team capacity on one screen using past velocity, days-off, and allocation, before you commit — inside the Jira backlog. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

FAQ

How do time zones actually affect sprint capacity?
They do not reduce raw person-days — a developer eight hours away still works a full day. What they reduce is collaborative bandwidth. Track your daily overlap window separately and treat stories that require real-time pairing across that boundary as higher-risk, not simply larger.

Should remote and in-office team members be estimated differently?
No. Estimate the work, not the person’s location. Location effects belong in the availability and allocation numbers, and in your historical points-per-person-day ratio, which already reflects how your specific hybrid team actually performs.

How many sprints of history do you need before the ratio is trustworthy?
Three is usable, six is better. If your team composition just changed — a detail ended, a contractor rolled off — reset the window and recalculate rather than averaging across two different teams.

Try this before your next sprint

Build one line per person for your next sprint: name, working days, days off, allocation percentage, net person-days. Total it, multiply by your points-per-person-day ratio, and compare that number to what your team was about to commit to. If the gap is more than 10%, you have found your carryover.

Try it: Install Sprint planning with Capacity Planning for Jira free · Read the help docs