The most common sprint planning anti-patterns in public-sector agile are committing to a deadline instead of to capacity, counting headcount instead of available days, and leaving no record of why a commitment was made. Each has a practical fix: plan from available days, calibrate with past velocity, and record the decision where the backlog lives.

Picture a program office that lost two contractors in a budget reshuffle. The milestone date didn’t move, the scope didn’t shrink, and the sprint board still shows 40 points of work. “Fewer people, same mission” is now a common operating condition across federal civilian, defense, and state and local programs. When staff is cut, guessing at capacity gets more expensive, not less.

What are the most common sprint planning anti-patterns in government agile?

Most of them come from reasonable pressures: fixed appropriations, fiscal-year deadlines, and reporting chains that want a single confident number. Teams respond by planning toward the date they were given rather than the time they actually have. The result is carryover, rework, and status reports that quietly change from green to amber in the last week of the sprint.

How do you fix each anti-pattern?

1. Committing to the deadline, not the capacity. The sprint goal is reverse-engineered from a milestone date. Fix: compute capacity first, then pull work until the number is reached. If the milestone needs more than the team can deliver, escalate the gap early instead of absorbing it silently.
2. Counting heads instead of days. “Six people, two weeks” ignores federal holidays, training mandates, leave, and people split across programs. Fix: count available person-days per person, and apply each person’s allocation to this team.
3. Using last sprint’s velocity unadjusted. Velocity from a full-staffed sprint gets reused for a sprint with a holiday and two people out. Fix: convert past velocity into points per available person-day, then multiply by this sprint’s available days.
4. Silent mid-sprint scope changes. Urgent requests get added with nothing removed, and nobody records the trade-off. Fix: any addition must name what comes out, and the swap is noted on the issue.
5. Capacity living in a side spreadsheet. The workbook goes stale, one person owns it, and it never lines up with the backlog. Fix: keep the capacity math next to the issues being planned, so the commitment and its basis are one artifact.

What does a corrected plan look like in numbers?

Take a six-person team planning a two-week sprint, November 2 to 13, in which Veterans Day (Wednesday, November 11) is a federal holiday.

• Working days: 10 minus 1 holiday = 9 days each, so 6 × 9 = 54 person-days.
• One developer is detailed 50% to another program: subtract 4.5, leaving 49.5.
• Planned time away: 3 days of leave plus 2 days of required training = 5, leaving 44.5 available person-days.

The last three sprints delivered 38, 41, and 35 points (114 total) on 50, 54, and 48 available person-days (152 total). That is 0.75 points per available person-day. Capacity for this sprint is 44.5 × 0.75 ≈ 33 points.

The backlog request was 40 points. Planning toward the deadline would have meant committing to 40 and carrying roughly 7 points over. Planning from capacity means committing to about 33, naming the 7-point gap on day one, and letting the product owner decide what moves. The conversation happens before the sprint starts instead of after it fails.

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

Each fix above is easy once. The hard part is doing it every sprint, for every team, when the person who built the spreadsheet is on leave. As agencies move planning work off spreadsheets and onto Atlassian Cloud, including Atlassian Government Cloud (AGC) for agencies that need it, the backlog becomes the natural home for the capacity math too.

That is what Sprint planning with Capacity Planning for Jira is for. It lets you plan sprints and team capacity on one screen, using past velocity, days-off, and allocation, before you commit, inside the Jira backlog. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

It also leaves a useful trail. Reviewers and leadership increasingly want to see what happened, who was allocated, what changed, and what supported the decision. A sprint record that shows who was allocated, which days-off were subtracted, and why the team committed to 33 points answers those questions in plain terms. To be clear, the app records planning decisions; it is a planning tool, not a compliance product.

A practical 90-day rollout: in the first month, run one team with capacity calculated alongside your current method and compare. In month two, add days-off and allocation for every team member. In month three, use the capacity number in your sprint review reporting and retire the side spreadsheet.

FAQ

How do you calculate sprint capacity for a government team?
Start with working days minus federal holidays, multiply by team size, subtract leave, training, and time allocated to other programs, then multiply the remaining person-days by your historical points per available person-day.

How many sprints of history do you need to calibrate?
Three completed sprints with recorded available days is a workable starting point. Use more as you collect them, and re-baseline when the team composition changes materially.

What should a team do when leadership insists on a date the capacity doesn’t support?
Present the capacity number, the gap in points, and the options: reduce scope, extend the date, or add capacity. A documented trade-off is easier to defend up the chain than a missed commitment.

Try it: Install free on the Atlassian Marketplace · Read the help docs