Ask a private-sector scrum master how big their team is and you get a number: “Eight engineers.” Ask a government program manager the same question and the honest answer is a paragraph. Two analysts are detailed to a surge effort across the agency through the end of the quarter. One developer is GS-staff at 30 hours a week on a flexible schedule. A contractor splits time 60/40 across two task orders on different contracts. Someone is in mandatory security training Thursday and Friday. “Eight” is a roster count, not a capacity number — and planning a sprint against the roster count is how government teams quietly overcommit, miss fiscal-year milestones, and end up explaining a slipped deliverable to a contracting officer.
The fix is not heroics. It is doing the arithmetic that turns a fuzzy roster into a defensible capacity number before you pull work into the sprint. Here is a framework that holds up when your team is a patchwork of part-time, detailed, and shared staff.
Why “headcount” lies in government
In most agencies, almost no one is 100% allocated to a single agile team. Detailing, reimbursable work, collateral duties, telework-and-training calendars, and split contract funding are the norm, not the exception. That means the gap between people on the org chart and people actually available to burn down sprint work is large — and it changes every sprint. If your planning starts from “we have eight people, last sprint we did 40 points, let’s pull 40 again,” you are anchoring on a number that assumes a fully present team you do not have.
Capacity planning for a mixed team means computing availability from the bottom up, person by person, every sprint. It is more arithmetic, but it is arithmetic you can show your leadership and your auditor.
A five-step framework
Work through these in order at the start of each sprint, before you commit to scope.
- Establish the gross sprint window. Start with working days in the sprint. A two-week sprint is typically 10 working days. Subtract agency-wide non-working days — federal holidays, org-wide closures, all-hands days — that apply to everyone.
- Set each person’s base allocation. For every team member, write down the percentage of their time that belongs to this team. The full-time GS developer is 100%. The analyst detailed half-time to the surge effort is 50%. The contractor on a 60/40 split is 60% to your task order. Do not round these up out of optimism.
- Subtract individual days off and commitments. Layer in person-specific reductions: approved leave, training days, recurring collateral duties, standing governance meetings. These come off the individual, not the team.
- Convert to a common unit. Decide whether you plan in hours or in story points, and convert consistently. If hours, multiply available days by productive hours per day (use 5–6, not 8 — meetings and email are real). If points, scale your historical velocity by the ratio of this sprint’s available capacity to a normal sprint’s.
- Hold back a buffer for the known-unknowns. Government work carries interruptions you can predict in aggregate even if not individually: data calls, urgent leadership requests, audit responses. Reserve 10–20% rather than planning to 100% and being surprised every sprint.
A worked example
Take a two-week sprint, 10 working days, with one federal holiday in the window — so 9 gross days available to everyone. The team roster is five people, but look at what the bottom-up math produces:
- Dana — full-time developer, 100% allocated, 2 days of leave. 8 days × 100% − 2 = 6 days
- Marcus — analyst, detailed 50% to a surge effort. 8 available days × 50% = 4 days
- Priya — contractor, 60% to your task order, 1 training day. 8 × 60% − 0.6 ≈ 4.2 days
- Lee — part-time GS, 30 hrs/week ≈ 75% schedule. 8 × 75% = 6 days
- Sam — full-time, 100%, but 50% on a standing accreditation duty this sprint. 8 × 50% = 4 days
Person-days available: 6 + 4 + 4.2 + 6 + 4 = 24.2 person-days. At roughly 5.5 productive hours per day, that is about 133 hours. Apply a 15% buffer and you have roughly 113 hours of committable capacity. Compare that to the naive estimate — “five people for two weeks” reads like 50 person-days or 400+ hours. The honest number is barely a quarter of the roster fantasy. Commit to the roster number and you have built failure into the sprint on day one.
Make it repeatable inside Jira
The framework is sound, but doing it in a side spreadsheet every sprint is where it breaks down. The spreadsheet drifts from the backlog, allocations get stale, and the moment someone’s detail changes, your plan is wrong and no one notices until standup. The value comes from doing the capacity math on the same screen where you pull the work.
That is the idea behind Sprint Planning with Capacity Planning for Jira: plan sprint scope and per-person capacity on one screen inside the Jira backlog, using past velocity, days-off, and each member’s allocation — so a 50% detail or a part-time schedule is reflected before you commit, not discovered after. Because it runs on the Atlassian Cloud platform, it is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform, which matters when your security office asks where the tooling lives. And because the capacity decision lives next to the work, you have a clear record of why you committed to what you committed to — useful when you are reporting predictability up the chain or answering for a milestone.
Try it: Install free · Help docs
1 Comment
Leave your reply.