A documented capacity decision — who was available, what was subtracted for time off and other duties, and why the team committed to a specific number of points — is what lets a government program answer “why did you commit to that” months later. That record, not any certification, is what protects a PMO under review.

Picture the scenario: an Inspector General review, a congressional staffer, or a new program executive asks why Sprint 14 missed its goal by six story points. The scrum master remembers “we were short-staffed,” but nobody wrote down who was actually out, what the team had available, or what number was agreed to going in. That gap — between a real decision and a documented one — is where government programs lose credibility, even when the underlying work was sound.

Why does sprint capacity documentation matter for government teams?

Oversight bodies increasingly expect a paper trail for delivery commitments, not just security events, and undocumented capacity decisions look like guessing when someone reviews them later.

Federal and state agencies already operate inside a documentation culture: GAO findings, agency Inspector General reviews, congressional data calls, continuous authorization packages. The current compliance climate — CMMC requirements flowing down to defense contractors, continuous ATO (cATO) renewal cycles, 24/48/72-hour incident reporting windows — has trained oversight bodies to expect one thing above all: evidence. Who acted, what changed, what supported the decision.

That expectation has quietly extended past security events into delivery management. When a program reports a missed sprint goal, “the team was busy” is not an answer. “Here is the roster we planned against, the days-off we subtracted, and the commitment we made based on historical velocity” is.

Most agile teams don’t have that second answer, because capacity planning is often done informally: a conversation in sprint planning, a gut-check on who’s around, a number pulled from memory. It’s rarely a record. And the stakes are rising — workforce reductions and flat or shrinking budgets are pushing agencies to deliver the same mission with fewer people, which makes the capacity math more consequential, not less. “We assumed everyone was available” gets harder to defend every budget cycle.

What should a documented capacity decision include?

A defensible capacity record needs five things: the full team roster considered, time subtracted for leave and training and holidays, any partial allocation to other work, the resulting available capacity, and a named reviewer.

1. Start from the full roster, not the usual suspects. List every person expected to contribute to the sprint, including anyone detailed in part-time from another team.
2. Subtract time off explicitly. Federal holidays, approved leave, training days — log each against the person and the sprint rather than estimating after the fact.
3. Account for partial allocation. Government developers are routinely split across programs, detailed a fixed percentage of their time to another initiative. Record the percentage, not just a mental note that “they’re mostly here.”
4. Translate capacity into a commitment using a stated method. Whether that’s trailing velocity, a focus factor, or an hours-to-points conversion, write down both the method and the resulting number, not just the final figure.
5. Name a reviewer and a date. A one-line sign-off — reviewed by the PM or delivery lead, dated — turns a plan into an artifact someone can point to later, instead of a conversation nobody can reconstruct.

How do you calculate a documented sprint capacity in practice?

Start with gross person-days, subtract holidays, leave, and detailed time, then apply the team’s historical points-per-day rate to reach a defensible commitment number.

Consider an eight-person development team planning a standard two-week, ten-working-day sprint:

• Gross capacity: 8 people × 10 days = 80 person-days.
• One federal holiday falls in the sprint: −8 person-days → 72 remaining.
• Two team members are detailed 20% of their time to another program for the remaining 9 days: −3.6 person-days → 68.4 remaining.
• One team member takes 3 days of approved leave: −3 person-days → 65.4 available person-days.
• Trailing three-sprint average rate: roughly 0.55 story points per available person-day (for example, 42 points delivered against 76 available person-days last sprint).
• Applying that rate: 65.4 × 0.55 ≈ 36 points — the defensible commitment, not 42, and not a round number chosen because it felt right.

Documented this way, if the sprint later lands at 34 of 36 points, the PMO has a one-page answer ready: the inputs, the math, and the person who signed off, all dated.

How does doing this inside Jira make it repeatable?

Keeping the roster, days-off, allocation percentage, and resulting capacity number on the same screen where the team commits to the backlog means the documentation happens as a byproduct of planning, not a separate compliance chore.

Spreadsheets can technically hold all five inputs above, but they live outside the system where the work actually happens, and they go stale, get overwritten, or disappear when the one person who maintained the tab changes roles. Sprint planning with Capacity Planning for Jira puts the team roster, days-off, and allocation percentage directly next to the sprint backlog, so the available-capacity number and the resulting commitment are calculated and captured together, sprint after sprint, inside Jira’s own history rather than a side file. As agencies move off spreadsheets and legacy Data Center instances toward Atlassian Cloud — including Atlassian Government Cloud for agencies that require it — this kind of planning record moves natively with the migration instead of needing to be rebuilt. The app itself is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001-audited platform, so the infrastructure underneath the record is independently audited, even though building the documentation habit is still on the program.

FAQ

Does documenting sprint capacity make an agency FedRAMP or CMMC compliant?

No. Disciplined capacity documentation creates a useful evidence trail for delivery decisions, and the app it’s built in is Cloud Fortified on Atlassian’s SOC 2 Type II / ISO 27001-audited platform. But FedRAMP authorization, CMMC certification, and continuous ATO are program-level compliance efforts owned by your security and compliance teams, not outcomes of any single planning tool.

Who should review and sign off on a sprint’s capacity plan?

Typically the scrum master or PM who ran the planning session, sometimes with a second sign-off from a delivery lead or PMO reviewer on programs with tighter oversight. The point isn’t hierarchy, it’s having one named person and date attached to the decision.

How far back should a program keep capacity history?

Enough to show a pattern rather than a single snapshot. Many programs align retention with their existing reporting cycle; a fiscal year is a practical baseline, since it lets leadership compare capacity and commitment trends across quarters.

Start small: before your next sprint planning session, write down the five inputs above for one team, one sprint. That single page is the start of an audit-ready capacity record.

Try it: Install free · Help docs