Key Takeaways
- To calculate team capacity when members are part-time or detailed elsewhere, convert each name into net availability, working days in the sprint minus that person’s days off, multiplied by their allocation percentage, then sum across the team and plan against that number rather than headcount.
- Headcount lies on government teams because details, inter-agency agreements, collateral duties like FOIA and security work, part-time schedules, and mandatory training all take fixed bites out of availability that velocity alone cannot correct for.
- Net capacity is routinely 40 to 60% below the nominal roster, so a board with six names can represent only about three and a half people once allocations and days off are counted.
- Count only the hands-on fraction of a scrum master or tech lead, since a lead who mostly reviews and unblocks may contribute 10 to 30% of a developer-equivalent, and counting them as 100% is a common source of quiet overcommitment.
- Sprint Planning with Capacity Planning for Jira puts past velocity, per-person days off, and allocation percentages on one screen inside the backlog, so you see net capacity against the proposed sprint before you commit and the plan becomes the record of what was assumed.
Answer first: To calculate team capacity when members are part-time or detailed elsewhere, convert each name into net availability — (working days in the sprint minus that person’s days off) multiplied by their allocation percentage — and sum across the team. Plan the sprint against that number, never against headcount.
A state eligibility-modernization team has six names on the Jira board. Look closer: one developer is detailed half-time to an audit response, the business analyst is split 60/40 across two programs, the tester works Tuesday through Thursday, and the tech lead writes code maybe a day a week. A scrum master who plans “for six” has lost the sprint before it starts. With hiring freezes and workforce reductions rolling through federal, state, and local agencies, this roster is becoming the norm: fewer people, same mission — and the details, collateral duties, and shared staff expand to fill the gap.
Why headcount lies on government teams
In a commercial product team, “a team of six” usually means six full-time people. In government it almost never does. Details and inter-agency agreements, collateral duties (contracting-officer support, security-control work, FOIA responses), phased-retirement and part-time schedules, reserve obligations, and mandatory training all take fixed bites out of availability. Velocity alone can’t correct for this: velocity is an average over past availability, and it has no way of knowing that this sprint you only get half of one developer. And because sprint commitments roll up to fiscal-year milestones, an optimistic commitment isn’t just a burndown-chart problem — it’s a number someone has to explain up the chain.
How do you calculate capacity when people are split across programs?
Five steps, in order:
- Put an allocation percentage next to every name. Not a job title — a number. The sources usually exist already: the detail memo, the inter-agency agreement, the tasking letter. If nobody can state what percent of a person this team actually gets, that is itself the finding; agree on a number at planning and record it.
- Count each person’s real working days for this sprint. Start from sprint weekdays, subtract holidays, then subtract that person’s approved leave, mandatory training, and drill days. Days off are individual, not team-wide — a Monday holiday costs nothing to someone who works Tuesday through Thursday.
- Multiply to get net person-days. Working days times allocation, per person, then sum. This is your real capacity, and it is routinely 40–60% below the nominal roster number.
- Turn capacity into a commitment. If you estimate in hours, compare demand to capacity directly. If you use story points, scale: divide this sprint’s net capacity by the average net capacity behind your recent velocity, and multiply average velocity by that ratio. Apply a focus factor — typically 70–85% for ceremonies and interrupt work — and apply it consistently.
- Write the math down and revisit it every sprint. Allocations drift, details get extended, training gets scheduled. A recorded calculation also gives you something increasingly valuable in the public sector: when leadership or an auditor asks why the team committed to 30 points and not 45, you can show who was allocated, what days were subtracted, and how the number was derived — evidence, not recollection.
A worked example: six names, three and a half people
Two-week sprint, ten weekdays, one state holiday — so nine base working days:
- Priya (developer, 100%): 9 − 2 days leave = 7.0
- Marcus (developer, 50% detailed to an audit team): 9 × 0.5 = 4.5
- Elena (business analyst, 60% allocated): (9 − 1 training day) × 0.6 = 4.8
- Sam (tester, works 3 days/week): 6.0
- Dana (developer, 100%): 9 − 2 days mandatory training = 7.0
- Jordan (tech lead, 20% hands-on): 9 × 0.2 = 1.8
Net capacity: 31.1 person-days against a nominal 54 (six people × nine days) — 58% of what the roster implies. Six names; roughly three and a half people. Apply an 80% focus factor and you have about 25 focused person-days. If the team’s recent velocity of 42 points was earned in sprints averaging 34 focused person-days, the supportable commitment is 42 × 25 ÷ 34 ≈ 31 points. Commit 30 and defend it with the arithmetic — don’t commit 42 and hope.
Making the calculation repeatable inside Jira
Most teams run this arithmetic in a spreadsheet that lives next to Jira — re-keyed every sprint, out of date by day three, and invisible to anyone reviewing the plan later. As agencies modernize from spreadsheets and self-hosted tooling to Atlassian Cloud — including Atlassian Government Cloud (AGC) — the planning math can move to where the work already lives. Sprint Planning with Capacity Planning for Jira puts past velocity, per-person days off, and allocation percentages on one screen inside the Jira backlog, so you see net capacity against the proposed sprint before you commit — and the plan itself becomes the record of what was assumed. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.
Before your next planning session, try a 15-minute roster audit: list every name on the team, write the true allocation percentage next to each, and flag any you can’t source to a document or a supervisor’s confirmation. Those flags are where your next failed sprint is hiding.
FAQ
How do you calculate sprint capacity for a part-time employee? Count only the days they actually work in the sprint on their schedule, subtract their personal days off, then multiply by their allocation if they also split across teams. A three-day-a-week tester in a two-week sprint starts from six days, not ten.
What allocation percentage should you use for a detailed employee? Use the percentage in the detail memo or agreement. If no document states one, don’t guess silently — agree on a number with the supervisor at planning, record it, and correct it next sprint if reality differs.
Do scrum masters and tech leads count toward capacity? Only their hands-on fraction. A tech lead who reviews, unblocks, and sits in governance meetings might contribute 10–30% of a developer-equivalent; counting them as 100% is one of the most common sources of quiet overcommitment.
Try it: Install Sprint Planning with Capacity Planning for Jira free · Help docs
Leave a Reply
Your email is safe with us.