Short answer: A government team new to agile should spend its first five sprints building trust in its numbers before it builds trust in its velocity: plan sprints 1 and 2 on capacity alone, treat sprint 3 as your first real data point, and use sprints 4 and 5 to blend capacity with an early velocity trend before reporting predictability to leadership.

Most government agile rollouts don’t collapse because a team can’t write a user story or run a stand-up. They collapse in month two, when a program manager reports a sprint commitment up the chain and the team delivers half of it — and nobody can explain why, because there was never a real plan to compare against, only a guess dressed up in agile vocabulary.

Why the First Five Sprints Look Different in Government

New agile teams in agencies are rarely stood up with slack. They’re often formed with fewer people than the workload calls for, absorbing scope from a program that just lost headcount or budget, and still expected to hit the same fiscal-year milestones as before — just “in an agile way” now. Whatever the team commits to in sprint planning also tends to get reported upward, into a monthly PMO roundup or a milestone review a program office has to defend. A commercial team that blows a sprint quietly adjusts and moves on. A government team that blows a sprint has to explain the miss to someone who wasn’t in the ceremony and doesn’t care about story points, only about the date. That’s why the first five sprints matter more than any that follow: they’re where a new team either earns the right to be trusted with its own estimates, or spends the next year rebuilding that trust after a bad first impression.

How Do You Onboard a Government Team to Agile in Five Sprints?

The fix isn’t a longer ramp-up or another training deck — it’s a deliberate five-sprint sequence that separates “how much can we do” from “how much did we say we’d do last time,” so the team never commits to a number it can’t defend.

1. Sprint 1 — Plan on capacity, promise nothing else. Calculate real hours or days available per person after holidays, training, and known leave, then commit to roughly 70–80% of that number. Don’t forecast past this sprint; the only goal is to run every ceremony once and get an honest number for “what we finished” on the board.
2. Sprint 2 — Same discipline, start logging the gap. Keep planning by capacity, not by last sprint’s output — there isn’t a “last sprint” worth trusting yet. Track what was planned against what was delivered, and write down why anything slipped: a changed requirement, a dependency, an absence. That log is the start of a decision trail, not busywork.
3. Sprint 3 — Your first real data point. The team now has one completed sprint of actual throughput. Treat it as a single data point, not a trend — one sprint can be skewed by a holiday week or a rough onboarding stretch. Compare it against the capacity-based plan to see how closely the team actually tracked.
4. Sprint 4 — Blend capacity with an early velocity signal. With two sprints of history, a cautious average starts to mean something. This is also where fiscal-calendar realities reassert themselves — quarter-end reporting, a training block, a contract transition — and where over-optimistic commitments tend to creep back in if nobody is watching.
5. Sprint 5 — Report predictability, not just output. A rolling three-sprint average, checked against capacity, is enough to make a defensible statement about next quarter. This is the sprint where the team can show a PMO a planned-versus-delivered trend instead of a single number, which is what actually earns trust upward.

A Worked Example: Five Sprints for a Nine-Person Modernization Team

Take a nine-person team — six developers, two testers, one business analyst — migrating a legacy case-management workflow into Jira as part of a broader move to Atlassian Government Cloud. Sprint 1 runs ten working days, minus one federal holiday, leaving nine. One tester is pulled for three days of mandatory security training, and one developer has two pre-approved leave days. That’s (9 people × 9 days) − 5 lost days = 76 person-days, or roughly 418 focus hours at 5.5 productive hours a day. Planning to 75% of that, the team commits to about 313 hours of backlog work — not a guess, a number built from who is actually available that sprint.

By sprint 3, the team has closed 28 of a planned 34 story points: 82% completion, and their first real data point. By sprint 5, the rolling three-sprint average sits at 30 points against an average plan of 33 — a gap the team can now explain in one sentence: normal variance from one contractor’s onboarding, nothing structural. That sentence, not a raw number, is what goes into the leadership report.

Why Do This on One Screen Inside Jira?

Running this five-sprint sequence across a spreadsheet, a slide deck, and the Jira backlog usually produces three different versions of “capacity” by sprint 3, because whoever updated the spreadsheet last wins. Planning capacity and the backlog on the same screen — past velocity, days-off, and allocation, checked before the sprint is committed — means the 75%-of-capacity call in sprint 1 and the rolling average in sprint 5 come from the same record every time, which is what a PMO actually wants to see in a review. Because that plan lives inside the Jira backlog on a Cloud Fortified app running on Atlassian’s SOC 2 Type II / ISO 27001–audited platform, the sprint-by-sprint history doubles as the documentation trail auditors and program offices ask for later, without anyone maintaining a parallel spreadsheet to produce it.

FAQ

Should a new government agile team estimate velocity from day one?
No. Plan the first sprint on capacity — hours or days actually available — alone. A real velocity trend needs at least three completed sprints before it means anything.

How much slack should a new team build into early sprint commitments?
Most new teams do better committing to 70–80% of calculated capacity in sprints 1 and 2, leaving room for the unknowns of new tooling, new ceremonies, and unclear dependencies.

When can a new team safely report predictability to leadership?
After sprint 5, once there’s a rolling average of at least three completed sprints to compare against the plan.

A practical first step, before opening any tool: write the sprint 1 capacity formula on paper — people, days, hours, minus leave and training — and pin it to the top of the backlog. Every later sprint gets measured against that one artifact.

Try it: Install free · Help docs