Two weeks into a sprint, a state agency’s modernization team realized the sprint was already lost. The board looked full and ambitious at planning. What nobody checked was that two of their five developers were detailed to a separate audit response, one was carrying mandatory annual security training, and the contractor’s option year hadn’t been renewed yet. The work was committed against people who weren’t actually available. By the retrospective, the team had carried over more than half the sprint — and the program manager had to explain the slip to a steering committee that only remembered the original commitment.
This is the gap between sprint planning and capacity planning. Most public-sector teams do one or the other. The ones that deliver predictably do both, together, in the same conversation.
Why the two halves drift apart in government
Sprint planning answers what will we build. Capacity planning answers who is actually here to build it, and for how long. In a commercial startup with a stable, full-time, co-located team, you can get away with treating capacity as roughly constant. Government teams almost never have that luxury.
The public-sector reality is fragmented availability. People are matrixed across programs. Contractors come on and off based on task orders and funding actions. Federal holidays, use-or-lose leave at fiscal year-end, mandatory training, and detail assignments all carve real hours out of a sprint without ever showing up on the backlog. When planning ignores those subtractions, the team commits to a capacity that exists only on paper — and the overcommitment lands as a credibility problem with the people you report to.
A practical framework for aligning the two
You don’t need a heavyweight process. You need to make capacity a visible input to the commitment decision instead of an afterthought. Here is a sequence that works for cautious adopters.
- Establish your true available hours first. Before anyone looks at stories, calculate the sprint’s real capacity. Start from each person’s working days in the sprint, subtract holidays, planned leave, training, and standing duties (the change-advisory board, the weekly program sync). Then apply a focus factor so you’re not pretending people code eight hours a day.
- Convert capacity into your planning unit. If your team plans in story points, translate available hours into a realistic point ceiling using recent velocity. If you plan in hours, you already have the number. The point is to end planning with a single figure: the most this team can responsibly take on.
- Plan the backlog against that ceiling, not above it. Pull stories until you approach the ceiling, then stop. Protect a buffer — government work attracts unplanned interruptions, from emergency data calls to oversight requests.
- Check allocation per person, not just the team total. A team can look balanced in aggregate while one senior developer is loaded to 130% and a junior sits at 40%. Over-allocation is where quiet sprint failures begin. Level the load before you commit.
- Write down the assumptions. Record who you assumed was available and for how much. When a detail gets extended or a holiday falls mid-sprint, you have a clear decision trail showing why the plan changed — which is exactly what a steering committee or auditor wants to see.
A short worked example
Take a six-person team running a two-week sprint, which is ten working days.
- Raw capacity: 6 people × 10 days × 6 productive hours = 360 hours.
- One federal holiday falls in the sprint: subtract 6 people × 6 hours = 36 hours.
- Planned leave and training: one developer out 3 days (18 hours), another in a 2-day certification (12 hours) = 30 hours.
- One developer is 50% detailed to another program for the whole sprint: subtract 30 hours.
True available capacity is 360 − 36 − 30 − 30 = 264 hours — about 27% below the headline number. If this team’s recent velocity is roughly one story point per four available hours, the responsible commitment is around 66 points, not the 90 the raw roster suggests. Planning to 90 is how you end up explaining a carryover. Planning to 66, with a small buffer, is how you finish what you start.
Making it repeatable inside Jira
The arithmetic above is not hard. Doing it consistently, sprint after sprint, in a spreadsheet that lives separately from the backlog, is where teams fall down. Numbers go stale, the spreadsheet owner goes on leave, and the next planning session quietly reverts to guessing from the roster.
The fix is to put capacity and the backlog on one screen, so the ceiling is visible at the exact moment you’re committing work. That is what Sprint Planning with Capacity Planning for Jira is built for: it lets you plan sprints and team capacity together inside the Jira backlog, drawing on past velocity, days-off, and per-person allocation, so you see over-allocation before you commit rather than discovering it in the retro. It runs on the Atlassian Cloud platform — it is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform — and keeping the planning record inside Jira means your capacity decisions are documented alongside the work, which makes reporting up the chain and reconstructing decisions later far easier.
Where to start
Pick your next sprint and try the framework manually once: compute true available hours, set a ceiling, level allocation, and write down the assumptions. If that single change improves your hit rate — and it usually does — make it permanent by bringing capacity into the backlog itself.
Try it: Install free on the Atlassian Marketplace · Read the help docs
Go deeper: see our complete sprint planning guide and the printable sprint planning checklist.
Leave a Reply
Your email is safe with us.