Short answer: Sprint planning with capacity on one screen means the scrum master sees past velocity, each person’s allocation, and their days off side by side in the Jira backlog, then commits to a number the team can defend. It takes about an hour instead of a morning of spreadsheet reconciliation.

It is the Monday before a sprint starts. Veterans Day lands mid-sprint, two people have training, and one analyst is detailed to another office half-time. The program office wants to know what will ship before the next status review. Here is what that planning day looks like when everything lives in one place.

Why does sprint planning drag on in government teams?

The data is scattered. Velocity lives in a Jira report, leave lives in an HR calendar or email, allocation lives in a staffing spreadsheet, and the backlog lives in Jira. Someone has to stitch them together by hand, and the result is usually a gut-feel number. With flat budgets and reduced headcount, “fewer people, same mission” is the norm, so a guessed commitment is more expensive than it used to be. Every missed sprint becomes a conversation up the chain.

What does a planning day look like step by step?

1. Start with the calendar, not the backlog. Count working days in the sprint and remove federal holidays. A two-week sprint with one holiday has 9 working days, not 10.
2. Set each person’s allocation. Record the share of their time that belongs to this team. A detailee at 50% counts as half a person.
3. Subtract days off. Planned leave, training, and known meetings come out before any story is pulled in.
4. Convert person-days to points using past velocity. Divide recent velocity by the person-days it took to deliver it. That gives you points per person-day, a ratio you can reuse.
5. Pull work until the total reaches capacity, then stop. Anything above the line is explicitly out of the sprint, not “stretch.”
6. Record the reasoning. Note who was allocated, what was subtracted, and why the team committed to N points.

What does the math look like? A worked example

This is an illustrative five-person team, not a customer case. The sprint runs November 2 to 13, with Veterans Day on November 11, so there are 9 working days.

• Ana: 100% allocated, no leave = 9.0 person-days
• Ben: 100%, 2 training days = 7.0
• Chloe: 50% detailed elsewhere = 4.5
• Dev: 100%, 3 days PTO = 6.0
• Eli: 80% allocated = 7.2

Total capacity: 33.7 person-days. Over the last three sprints the team averaged 42 points across 40 person-days, or 1.05 points per person-day. Capacity in points: 33.7 x 1.05 = about 35 points.

If the team simply repeated its 42-point average, it would be committing about 7 points (20%) more than the people available can deliver. That gap is the usual origin of carry-over and surprise slips.

How does this help when you report upward?

Leadership rarely asks about points. They ask, “Why is this sprint smaller?” The answer becomes one sentence: “Nine working days, one holiday, five days of leave and training, and one half-time detailee, so we committed 35.” That is a record of who was allocated, what was subtracted, and what evidence supported the decision. It is documentation of a planning decision, which is useful in any review, though it is not a compliance product.

Why do it inside Jira?

Agencies moving off spreadsheets and onto Atlassian Cloud, including Atlassian Government Cloud (AGC) for those who need it, want planning to sit next to the work itself. Sprint planning with Capacity Planning for Jira puts velocity, allocation, and days-off on the backlog screen, so the six steps above become one repeatable view rather than a new spreadsheet each sprint. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. Divim itself does not hold independent security certifications.

FAQ

How long should sprint planning take with capacity data ready?
A common guideline is up to two hours per week of sprint length, and teams with capacity pre-calculated usually finish well within that.

Do we need story points to use this approach?
No. The same ratio works with hours or issue counts, as long as you measure velocity and available time in consistent units.

What if velocity is unstable?
Use the average of the last three to five sprints, and review the ratio whenever team composition changes.

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

Practical next step: before your next planning session, build a one-row-per-person capacity worksheet using the six steps above and compare it to your usual commitment.