A sprint commitment you can’t reconstruct later is a liability in government delivery. Recording who was available, what was subtracted and why, and how the commitment number was derived turns each sprint’s capacity decision into evidence a program can stand behind — through leadership changes, data calls, and formal reviews.

Here is how programs usually discover the gap. A new program executive inherits a delivery program in month seven of the fiscal year. The scrum master who ran every planning session accepted the early-retirement offer during the last workforce reduction. Jira still shows the sprints — commitments of 41 points, then 28, then 35 — but nothing says why. Was 28 a staffing dip or a team losing its footing? Nobody left on the program can say. Every number now looks arbitrary, including the ones that were exactly right.

That is the quiet cost of undocumented capacity decisions. The program didn’t lose the knowledge when it made those plans. It lost it when the one person holding it walked out the door.

Why do sprint commitments need a decision trail in government?

Because the oversight culture around them already runs on evidence, and delivery is being pulled into it. CMMC assessments rolling down to defense contractors, continuous ATO renewal cycles, and 24/48/72-hour incident-reporting windows have trained agencies and their vendors on one operating rule: be able to show who acted, what changed, and what evidence supports the decision. Delivery reviews are inheriting that same expectation. When leadership asks mid-year whether a team can absorb a new mandate, “we think so” carries no weight. Three quarters of documented capacity plans set against actual delivery does.

There is also a colder reason: continuity. Flat budgets and workforce reductions mean government teams run leaner, with more single points of failure. Fewer people, same mission — and fewer people who remember why last quarter’s commitments were what they were. A capacity record is not bureaucratic overhead. It is institutional memory that survives the person who created it.

One distinction matters before the how-to: this is governance hygiene, not a certification exercise. A capacity record does for delivery what a decision memo does for acquisition — it documents a judgment so the judgment can be examined. No certification is required to start, and none results from it.

How do you build a capacity decision trail?

Four practices turn routine sprint planning into a record that holds up later.

1. Baseline before the sprint starts, not after. Capture the plan — roster, deductions, commitment — at the moment the team commits, with a date on it. A plan reconstructed after the fact is a narrative; only a baseline recorded before the work began is evidence.
2. Make every subtraction a named line item. Mandatory training, approved leave, a percentage detailed to another tasking, a frozen vacancy: each gets its own line with a person, an amount, and a reason. Resist the blended “focus factor.” A single fudge number can’t be defended line by line; a list of named deductions can.
3. Write the method next to the number. Availability-scaled velocity, points per person-day, hours with a conversion — any of these can be honest, but none is defensible if unstated. The record should show method, inputs, and result, so a reviewer can re-run the math without you in the room.
4. Record what you deferred. Descoping is the other half of the decision. Listing the stories moved out to fit the commitment shows the number was chosen deliberately, not defaulted into — and it answers the follow-up question (“what didn’t fit?”) before it’s asked.

What does a documented capacity decision look like in numbers?

Take a six-person team planning a two-week sprint with ten working days:

• Gross capacity: 6 people × 10 days = 60 person-days.
• Agency-wide security-awareness training, a half day for all six: −3 person-days.
• One engineer on four days of approved leave: −4 person-days.
• One engineer detailed at 50% for the full sprint to a congressional data call: −5 person-days.
• Available: 48 of 60 person-days — 80% availability. (The team’s seventh seat is vacant and frozen; it appears in the record as a note, not in the math, because it isn’t real capacity.)
• History: the past three sprints averaged 33 delivered points at an average 88% availability.
• Commitment: 33 × 80 ÷ 88 = 30 points.

The record closes with one line: “Deferred two stories (8 points) to fit capacity. Reviewed by the delivery lead,” plus the date. Months later, when someone asks why a team that had been delivering 33 points committed to 30, the program has a one-page answer with the math attached.

Where should the record live?

Not in a side spreadsheet — that is precisely the artifact that leaves with its owner. The record earns its keep when it lives in the same system as the work. Sprint Planning with Capacity Planning for Jira puts the team roster, days-off, and per-person allocation on one screen with the sprint backlog, calculates available capacity against past velocity before the team commits, and does it inside the Jira backlog — so the decision trail accumulates sprint after sprint as a byproduct of planning rather than a separate chore. As agencies modernize from spreadsheets and aging Data Center instances to Atlassian Cloud — including Atlassian Government Cloud (AGC) where required — that planning history moves with the platform instead of being rebuilt. On status, precision matters: the app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. Those are Atlassian’s platform attestations, not DiViM’s — the app records planning decisions; it is not a compliance product.

FAQ

Is a sprint capacity record required by any regulation?

Generally no — no rule mandates documenting sprint capacity. Its value is practical: cheaper data calls, smoother program transitions, and commitments that stand up in reviews. Formal compliance obligations such as CMMC or an ATO are owned by your security and compliance functions and are not affected by planning tooling either way.

What is the minimum viable capacity record?

One page or one screen per sprint: roster, named subtractions, the availability percentage, the method, the commitment, what was deferred, and a reviewer with a date. If it takes more than ten minutes at planning, it’s over-built.

Who owns the record after the scrum master leaves?

If it lives in shared tooling, nobody has to — it stays with the program. That is the real test of a capacity record: it is still legible after its author is gone.

A practical way to start: for the next sprint, write the baseline by hand — the four practices above fit on one page. Compare plan against actual for the two sprints after that. By the end of the quarter you will have the beginnings of the evidence trail this article describes, and a clear sense of whether tooling should take over the bookkeeping.

Try it: Install Sprint Planning with Capacity Planning for Jira free on the Atlassian Marketplace · Help docs

admin

See Full Bio