Why document sprint capacity decisions? Because when an oversight office, auditor, or new program director asks why a team committed to N points, a written record of who was allocated, which days were subtracted, and what past velocity said turns a memory-based debate into a two-minute answer. Documentation is a planning discipline, not a compliance product.

It is the week after a reorganization. Two positions were not backfilled, a deputy asks why the Q2 release slipped, and nobody can reconstruct what the team believed it could deliver when it committed. The spreadsheet was overwritten. The chat thread is gone. Everyone remembers a different number.

Why does the decision trail matter now?

Public-sector buyers increasingly reward practices that help them show what happened, who acted, what changed, and what evidence supported a decision. That pressure comes from many directions: shrinking budgets, workforce reductions, new acquisition models, and heavier scrutiny on how delivery commitments are made. “Fewer people, same mission” makes the capacity conversation sharper, because every promise now has to be defended against a smaller team.

Sprint planning already produces decisions. The gap is that most agencies do not record them in a form that survives staff turnover. This article is about closing that gap with ordinary planning habits.

What should a capacity decision record contain?

Keep it to five items per sprint. If a record takes more than a few minutes to produce, it will not be produced.

1. Who was planned in, and at what allocation. Name each person and the percentage of their time on this program, including anyone detailed elsewhere.
2. Days removed. Federal holidays, approved leave, training, and mandatory agency events, each with the number of days.
3. The velocity evidence. The last three sprints’ completed points and the available days behind them.
4. The commitment and the reasoning. The points committed and one sentence on why that number, not a higher one.
5. Changes after commitment. Scope added or removed mid-sprint, who approved it, and the effect on capacity.

How do you build the record into the sprint routine?

Four habits make the record stick. Capture it at planning, not afterward, because reconstructed records are guesses. Store it where the work lives, because a record kept in the backlog tool stays attached to the sprint it describes while a separate file drifts. Record the reasoning, not only the result: “Committed 34 because 42.5 available days at 0.8 points per day” is defensible, while “Committed 34” is not. And review it at the retrospective, comparing commitment to outcome, because a pattern of misses is a planning finding the record shows early.

What does this look like with real numbers?

This is an illustrative example, not customer data. A six-person team plans a two-week sprint that includes the Columbus Day federal holiday, leaving 9 working days.

• Five people at 100%: 5 x 9 = 45 days. One person at 50%: 4.5 days. Gross: 49.5 days.
• Approved leave: minus 4 days. Mandatory training: minus 3 days. Available: 42.5 days.
• The last three sprints delivered 38, 42, and 40 points on an average of 50 available days, so average velocity is 40 and the rate is 0.8 points per available day.
• Forecast: 42.5 x 0.8 = 34 points.

The team commits to 34, not the 40 it “usually” does. Three weeks later, if a stakeholder asks why the sprint delivered 34, the record answers it: a holiday, 4 leave days, and 3 training days. Nobody needs to reconstruct anything.

How does doing this in one tool inside Jira make it repeatable?

A record only helps if it exists every sprint. The hard part is not knowing what to capture; it is capturing it consistently when sprint planning is already crowded. When allocation, days-off, and past velocity sit on the same screen as the backlog, the numbers behind a commitment are visible at the moment the team commits, and they stay attached to the sprint.

That is the idea behind Sprint planning with Capacity Planning for Jira: plan sprints and team capacity on one screen using past velocity, days-off, and allocation, before you commit, inside the Jira backlog. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. It records planning decisions; it is not a compliance product, and DiViM does not hold its own security or compliance certifications. For agencies moving off spreadsheets and toward Atlassian Cloud, including Atlassian Government Cloud (AGC), this keeps capacity planning in the same place as the work.

A 90-day starting point

In the first month, add the five-item record to every sprint planning meeting by hand. In the second, compare commitments to outcomes at each retrospective. In the third, move the record into your planning tool so it no longer depends on one person’s discipline.

FAQ

Does documenting sprint capacity make an agency compliant with anything?

No. It creates a clear planning record that supports honest reporting and easier handoffs. Compliance frameworks have their own requirements and should be addressed through your agency’s security and compliance processes.

How long should a capacity record be?

Five items, a few lines each. If it takes more than a few minutes, simplify it.

Who should own it?

The scrum master or delivery lead captures it; the product owner and team confirm the commitment. Ownership matters less than doing it every sprint.

Try it: Install free on the Atlassian Marketplace · Help docs