The five sprint planning anti-patterns that most often derail public-sector agile teams are treating velocity as a quota, planning with ghost capacity, ignoring the calendar, committing without a documented rationale, and absorbing staffing cuts without recalculating capacity. Each one is fixable by grounding every sprint commitment in an explicit, recorded capacity calculation before the team commits.

Here is a scene familiar to many agency PMOs: the sprint review slides show another miss — 34 points planned, 24 delivered — and the program manager is asked, again, why the team “can’t hit its numbers.” Nobody in the room can reconstruct why 34 was the commitment in the first place. That is not a velocity problem. It is a planning process problem, and it usually traces back to a handful of recurring anti-patterns.

Why do these anti-patterns hit government teams harder?

Government delivery environments amplify planning mistakes. Fixed fiscal-year deadlines mean a bad quarter cannot simply slide. Staff are routinely detailed to other programs, sit on review boards, and carry mandatory training obligations that private-sector teams rarely face. And with workforce reductions and flat budgets across FedCiv, DoD, and State & Local, many teams are running the same mission with fewer people — which makes knowing real capacity before committing more important, not less. Finally, accountability runs upward: when a sprint misses, someone above the team will ask what happened, and “we guessed” is not an acceptable answer.

What are the five most common sprint planning anti-patterns (and their fixes)?

1. Velocity as a quota

Leadership sets a “target velocity” — often last sprint’s best number — and the team plans to it regardless of who is actually available. Velocity becomes a performance metric instead of an observation, and teams start inflating estimates to protect themselves.

Fix: Treat trailing velocity (average of the last three to five sprints) as an input to planning, never a goal. The commitment for any given sprint should come from that input adjusted for this sprint’s actual capacity.

2. Ghost capacity

The roster says six people, so the plan assumes six full-time people. In reality, two are detailed 50% to another program, one supports a legacy system “as needed,” and one chairs a change control board. The plan is built on capacity that does not exist.

Fix: Record an allocation percentage for every team member every sprint. If someone is 50% allocated, they contribute half a person — write it down and plan accordingly.

3. Calendar blindness

The sprint spans a federal holiday, two people have use-or-lose leave, and one developer has three days of mandatory training — none of which appears in the plan. The team then “underperforms” against a number that assumed days that were never available.

Fix: Subtract holidays, approved leave, and training days person by person before setting the commitment. Ten minutes of calendar arithmetic prevents a retrospective full of excuses.

4. The undocumented commitment

The team commits to N points in a meeting, and the reasoning evaporates when the meeting ends. Six weeks later, an oversight question arrives — why did the program commit to this scope? — and nobody can show who was allocated where, which days off were subtracted, or what velocity assumption was used. In a climate where agencies are increasingly expected to prove what happened, who acted, and what evidence supported a decision, an unreconstructable commitment is a liability.

Fix: Make the capacity math part of the sprint record: roster, allocations, days off, trailing velocity, resulting commitment. Disciplined planning leaves a decision trail by default.

5. Absorbing cuts without recalculating

The team loses a developer to a reassignment or a hiring freeze, but the commitment stays where it was “because the deadline didn’t move.” Two sprints later, the team is demoralized and the burndown is fiction.

Fix: Recompute capacity from the current roster every single sprint. Fewer people means a smaller commitment — surfacing that honestly is what lets leadership re-scope or re-prioritize while there is still time.

How does the capacity math work in practice?

Take a six-person team planning a two-week sprint (10 working days):

• Naive capacity: 6 people × 10 days = 60 person-days
• Federal holiday mid-sprint: −6 person-days (one day, everyone)
• Two members detailed 50% to another program: −9 person-days (half of their remaining 9 days each)
• One developer in mandatory training for 3 days: −3
• One analyst on approved leave for 2 days: −2

Real capacity: 40 person-days — a third less than the naive number. If the last three sprints averaged 34 points delivered on roughly 45 available person-days, the team’s rate is about 0.75 points per person-day. This sprint’s evidence-based commitment is therefore 40 × 0.75 ≈ 30 points, not the 34-plus a quota-driven plan would demand. Committing to 30 and delivering 30 builds more credibility up the chain than committing to 36 and delivering 26 — every time.

Making the fix repeatable inside Jira

Every fix above is simple; the failure mode is doing them in a side spreadsheet that goes stale, disagrees with the backlog, and disappears when the scrum master rotates out. As agencies modernize onto Atlassian Cloud and Atlassian Government Cloud (AGC), the practical move is to do this arithmetic where the work already lives. Sprint Planning with Capacity Planning for Jira puts past velocity, per-person allocation, and days off on one screen inside the Jira backlog, so the team sees real capacity before it commits — and each sprint’s plan leaves a record of the assumptions behind the commitment. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

A practical way to start: for your next sprint only, run the five-line calculation above in planning and write the result at the top of the sprint goal. If the commitment it produces differs from what the team “usually takes,” you have found your anti-pattern.

FAQ

Is a lower velocity a sign the team is failing?
No. Velocity is a descriptive measure of a specific team’s output under specific conditions. A team that commits to its real capacity and delivers it is healthier — and more useful to leadership — than one chasing a quota and missing.

How do we stop leadership from treating velocity as a target?
Show the capacity math alongside the number. When leadership can see that 40 person-days went into a 30-point commitment, the conversation shifts from “why so low?” to “what would it take to add capacity?” — a far more productive question.

Which anti-pattern should we fix first?
Calendar blindness. Subtracting holidays, leave, and training is the fastest fix with the most immediate effect on predictability, and it requires no process change beyond ten minutes in sprint planning.

Try it: Install Sprint Planning with Capacity Planning for Jira free · Help docs

admin

See Full Bio