To calculate real sprint capacity when staff are part-time, detailed to another program, or shared across teams, multiply each person’s available working days in the sprint by their FTE allocation percentage, subtract planned leave and known pulls, and convert the result to points or hours using that person’s own historical output — never a flat team average. Skipping this step is one of the most common causes of blown sprints in agencies running lean, mixed-status teams.

A PMO lead at a state transportation agency described her team roster this way: eight names on the sprint board, but only about five “whole” people’s worth of work in any given two-week window. Two developers split their time between her modernization program and a legacy maintenance contract. A QA analyst was detailed to a security review for half the quarter. A contractor’s hours were capped by the task order. On paper, capacity planning looked like counting heads. In practice, every sprint she ran using headcount instead of hours came in over-committed.

This is not a fringe scenario in government agile — it’s close to the median. Detailing staff, part-time backfills, shared-services arrangements, and fixed-hour contractor ceilings are structural features of how agencies staff programs, especially now, with flat-to-shrinking budgets and hiring freezes pushing more work onto fewer people. Treating capacity as a body count instead of a measured quantity is why so many public-sector teams either sandbag their commitments to stay safe, or blow through them and have to explain the miss up the chain.

Why Flat Capacity Math Breaks Down in Government Teams

Commercial capacity guides usually assume a stable, mostly full-time team. Government reality is different: staff are matrixed across programs, detailed for temporary duty or emergency response, capped by task-order hours, or rotating through training and certification requirements that eat entire days. A PM who counts “eight developers, therefore roughly 80 story points” is really just guessing, and the guess gets worse every time the roster changes — which in a detailee-heavy environment is often.

The fix isn’t complicated, but it does require tracking capacity at the individual level and rolling it up, rather than working from a team-wide average.

How Do You Calculate Sprint Capacity When Staff Are Part-Time or Detailed?

• Start from working days, not headcount. For each person, take the number of working days in the sprint and multiply by their FTE allocation to this team — 100% for full-time, 50% for a half-time detail, and so on.
• Subtract known absences and pulls. PTO, federal holidays, training, and any pre-scheduled detail days come out of that person’s available days before the sprint starts.
• Hold a contingency line for unplanned pulls. Incident response, all-hands taskings, and last-minute details are common enough on government teams that a 10–15% buffer against total capacity is realistic, not pessimistic.
• Convert days to points using each person’s own velocity, not the team’s. A developer working 50% time doesn’t produce half the points of a full-time developer on a like-for-like basis — their ramp-up and context-switching costs are proportionally higher. Track output per person over three to five sprints and use that individual rate.
• Recalculate capacity every sprint, not once a quarter. Details change, task orders get amended, and people rotate off. A capacity number from two sprints ago is a stale number.

A Worked Example: An Eight-Person Team With Four Detailees

Take a 10-working-day sprint for a team of eight, where the scrum master doesn’t carry a development load:

• Dev A — 100% FTE, no leave: 10 available days
• Dev B — 100% FTE, 2 days PTO: 8 available days
• Dev C — 50% FTE, detailed 2 days a week to a legacy maintenance contract: 5 available days
• Dev D — contractor capped at 60% of sprint hours by task order: 6 available days
• Dev E — 75% FTE, 1 mandatory training day: 6.5 available days
• Dev F — 100% FTE, pulled 3 days mid-sprint for incident response: 7 available days
• QA G — 100% FTE, no leave: 10 available days

Total available capacity: 52.5 person-days. Looking at the team’s last three sprints, they’ve averaged roughly 0.9 story points per available person-day. Multiply it out: 52.5 × 0.9 ≈ 47 points of raw capacity. Apply a 10% contingency buffer for the kind of unplanned pull Dev F just experienced, and the team should commit to roughly 42 points — not the 60-plus points an eight-person roster might suggest at first glance.

That gap — 42 committed versus a naive headcount estimate well above it — is exactly the difference between a sprint a PMO can defend in a status report and one that needs an explanation for why it slipped.

Doing This on One Screen Instead of a Side Spreadsheet

The math above is straightforward, but doing it by hand in a spreadsheet every two weeks, then re-keying the result into Jira, is where most teams quietly stop maintaining it. Sprint planning with Capacity Planning for Jira keeps individual allocation percentages, days-off, and past velocity next to the backlog itself, so a PM can see real available capacity — person by person, detail by detail — before the team commits to a sprint, without leaving the backlog screen or reconciling a separate file. Because the numbers live where the planning happens, updating a detailee’s allocation or logging a mid-sprint pull takes a few clicks, not a spreadsheet rebuild, which makes it realistic to recalculate capacity every sprint the way the framework above requires. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001-certified cloud platform.

FAQ

How do you count a part-time or detailed team member’s velocity?
Track their completed points against their own available days over several sprints, not the team average. A person working 50% time typically completes somewhat less than half of a full-time peer’s output per available day, because context-switching and onboarding costs scale with fragmentation, not just hours.

Should detailees be included in sprint capacity at all?
Yes, at their actual available percentage. Excluding them entirely undercounts real capacity, and counting them as full-time overcounts it. Both errors produce the same result: a commitment the team can’t hit.

How much contingency buffer should a government team hold?
Most teams with frequent unplanned pulls — incident response, all-hands taskings, ad hoc details — do well with 10–15% held back from calculated capacity. Teams with more stable staffing can run closer to their full calculated number.

Related guide: once capacity math works for one team, the next challenge is doing it across several — see our guide to capacity planning for multi-team, scaled agile in large agencies.

Try it: Install free · Help docs