To plan capacity for a hybrid or distributed government team, build one shared availability calendar in each person’s local time, subtract every real day off — including compressed-schedule regular days off — identify the hours the whole team is actually online together, and scale your past velocity by the availability that remains. Commit to that adjusted number, not to your roster headcount.

When “six people for two weeks” isn’t six people for two weeks

Picture a common federal program team: three analysts at headquarters on Eastern time, two engineers in a regional office on Central, and one full-time teleworker on Pacific. On paper it is six people and a ten-day sprint — plenty to clear the committed backlog. Two weeks later the sprint misses by a third, and no one slacked off. The capacity was never really there. Two of the six were on compressed schedules with a regular day off falling inside the sprint, one had approved leave, and the three time zones left the whole team overlapping for only a couple of hours a day.

This is the new normal, not an edge case. As agencies consolidate real estate, slow hiring, and lean harder on telework, “fewer people, same mission” increasingly means fewer people spread across more places. When a team is distributed, capacity planning stops being optional bookkeeping and becomes the difference between a commitment you can keep and one you will quietly break.

Why distributed government teams overcommit

Hybrid and distributed teams tend to overcommit for three specific reasons, and none of them are about effort.

• Headcount hides schedule fragmentation. Alternative work schedules — the 5/4-9 and 4/10 patterns common across the federal workforce — mean a two-week sprint is rarely ten working days for everyone. Someone almost always has a regular day off (an “RDO”) inside the sprint window.
• Time zones shrink the real collaboration window. When only a few hours overlap, dependent work — code reviews, approvals, pairing — queues up and waits for the next overlap, so throughput drops even when everyone is technically “available.”
• Availability is scattered. One person’s telework agreement lives in email, another’s leave is on a shared calendar, a contractor’s schedule sits in a spreadsheet. With no single source of truth, planners default to headcount because it is the only number they can see.

A five-step framework for hybrid capacity

You can plan a distributed team’s capacity honestly in about fifteen minutes with a repeatable sequence.

1. Build one shared availability calendar — in local time. List every team member with their time zone, their telework pattern, and any alternative or compressed work schedule. Mark the RDOs. This single view is what replaces the guesswork.
2. Find the core overlap window. Identify the hours when the entire team is online at once. Schedule sprint ceremonies and any cross-person dependencies inside that window, and deliberately route independent, heads-down work outside it.
3. Subtract real days off, person by person. Take roster capacity (people × sprint days) and remove RDOs, approved leave, training, and details to reach net available person-days.
4. Scale past velocity by availability — don’t re-estimate from zero. Because your velocity was earned by this same distributed team, it already reflects their time-zone overhead and handoff costs. Multiply your reference velocity by the availability ratio to get a defensible commitment, then hold a small buffer for cross-time-zone handoffs.
5. Write down the assumptions. Record who was available, what you subtracted, and what the team committed to. That short note is your decision trail when a stakeholder later asks why the sprint held 34 points instead of 40.

A worked example

A six-person team runs two-week sprints, so roster capacity is 6 × 10 = 60 person-days. For the coming sprint:

• Two engineers on 5/4-9 compressed schedules each have one RDO in the sprint: −2 days.
• One analyst has three days of approved annual leave: −3 days.
• One engineer is detailed to another office for a day: −1 day.

Net available is 60 − 6 = 54 person-days, or 90% of the roster (54 ÷ 60). The team’s reference velocity, averaged over the last three sprints, is 40 story points. Scaling by availability gives 40 × 0.90 = 36 points. Because two stories depend on reviews from the Pacific-time teleworker — and those reviews can only happen in the narrow daily overlap — the team holds about 5% back and commits to 34 points. That number is not pessimism; it is the roster velocity corrected for who is actually there and when they can actually work together.

Why this belongs in one place inside Jira

The framework works on a whiteboard once. The hard part is doing it every sprint, for every team, without the availability data drifting back into scattered emails and spreadsheets. That is where modernizing on Atlassian Cloud earns its keep: instead of reconciling calendars by hand, the planning happens on the same platform the work already lives on. Divim’s Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and per-person allocation on one screen inside the Jira backlog, so you can see a distributed team’s real capacity before you commit — and adjust the sprint scope while everyone is still in the room. Because it records who was allocated, which days were subtracted, and why the team committed to N points, it also leaves a documentation trail for how the decision was made. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform, the same foundation agencies rely on as they move to Atlassian Government Cloud (AGC).

Capacity is only one of three forces that move a delivery date after it is set. On a program with a hard commitment, it pays to watch all three together: scope creep, late dependencies, and capacity changes each quietly erode a committed release date once the plan is locked — and capacity is the one teams most often forget to update.

FAQ

How do you calculate capacity for a team spread across time zones?
Start from roster capacity (people × sprint days), subtract every real day off including compressed-schedule RDOs and leave, then scale your historical velocity by the remaining availability. Keep a small buffer for work that can only happen during the team’s overlapping online hours.

Do compressed or alternative work schedules change sprint capacity?
Yes. A 5/4-9 or 4/10 schedule means at least one regular day off per pay period, so a “ten-day” sprint is often eight or nine working days for those team members. Counting those RDOs is one of the biggest single corrections you can make.

Should distributed teams lower their velocity assumption?
Not separately. If your velocity comes from the same distributed team, it already includes their coordination overhead. Scale that velocity by availability rather than applying an extra “remote” discount, which would double-count the cost.

Try it: Install free · Help docs