Short answer: A government team new to agile should use its first five sprints to install one planning habit per sprint — count real availability, record why you committed to the number, protect the sprint boundary, make shared staffing explicit, and report the trend instead of a single sprint. By sprint 5, the team has both a working process and a record that can defend every commitment up the chain.

Here is how the first sprint usually goes wrong. A state human-services agency reorganizes and its eligibility-systems team shrinks from eight people to six. The modernization deadline does not move; the team is told to “go agile,” and leadership quietly hopes the new method will absorb the difference. Sprint 1 gets planned to eight people’s worth of work out of habit, delivers barely half, and the very first sprint report that goes up the chain lands badly. From then on, every estimate the team produces is discounted — and agile itself takes the blame.

Why Agile Onboarding Fails Differently in Government

A commercial team gets a grace period; a new government agile team inherits its obligations on day one. There is a fiscal-year milestone that predates the team, a monthly report a program office must defend, and, increasingly, an oversight environment that rewards teams who can show what happened: who was available, what was subtracted, and why the commitment was the size it was. Vocabulary training does not produce any of that. Planning habits do. So the goal of the first five sprints is not to “do agile correctly” — it is to install five habits, one per sprint, each of which leaves a small piece of evidence behind.

What Should Each of the First Five Sprints Accomplish?

1. Sprint 1 — Count who is actually there. Before estimating anything, build an availability table: each person’s allocation percentage to this team, minus holidays, approved leave, and training time. Commit to roughly two-thirds of what is left. A new team’s first commitment should be embarrassingly easy to hit — the win is finishing what was promised, at any size.
2. Sprint 2 — Write down why the number is the number. Add one short paragraph to the sprint record: the availability inputs, the buffer applied, and what the team chose to leave out. This is the start of a decision trail. When someone asks in October why the team committed to N points, the answer exists in writing instead of in someone’s memory.
3. Sprint 3 — Protect the boundary. Mid-sprint additions are the quiet killer of new government teams, because “small” requests from a program office rarely feel refusable. The habit: nothing enters the sprint without something of equal size leaving, and both moves are logged. This sprint also produces the team’s first real throughput number — treat it as one data point, not a trend.
4. Sprint 4 — Make shared staffing explicit. Most agency teams borrow people: a tester split with an operations contract, an analyst shared with a reporting program. Map every member’s real allocation and compare it with what sprints 1–3 assumed. This is where over-allocation surfaces — the person planned at 100% who was never more than half yours — and where percentages get renegotiated with the other program instead of silently absorbed.
5. Sprint 5 — Report the trend, not the sprint. With three completed sprints, show leadership planned-versus-delivered across all three, with a one-sentence explanation for each gap. A trend with explanations reads as control. A single number, good or bad, reads as luck.

A Worked Example: Sprint 1 for a Six-Person State Team

Take that six-person eligibility team planning a two-week sprint — ten working days, minus one state holiday, so nine. Three full-time developers contribute 27 person-days. A fourth developer has three days of approved leave: 6. The tester is allocated 50% to an operations contract: 4.5. The business analyst is split 50% with a reporting program: 4.5. Real capacity is 42 person-days — against the 60 the roster implies if you count six heads for two weeks and ignore everything else. Nearly a third of the paper capacity was never real. Committing to two-thirds of the 42 — about 28 person-days of backlog work — gives the team a sprint it can actually finish, and a written reason for every day subtracted.

By sprint 3, the team delivers 19 of 24 committed points — 79%, its first data point. Across sprints 3–5 the average is 21 delivered against 23 planned, and each gap has a one-line cause in the record: one late environment approval, one underestimated interface story. That is the report that goes up the chain.

Why One Screen Inside Jira Makes the Habits Stick

Habits survive only if they are cheap. If the availability table lives in a spreadsheet, the sprint record in a slide deck, and the backlog in Jira, sprint 6 is where the spreadsheet stops being updated — and the decision trail dies with it. Doing the same work where the backlog already lives — past velocity, days-off, and allocation on one screen, checked before the team commits — turns the five habits into a ten-minute planning step instead of a parallel bookkeeping job. For agencies consolidating tools as part of a move to Atlassian Cloud or Atlassian Government Cloud (AGC), it is also one less spreadsheet living outside the platform: Sprint Planning with Capacity Planning for Jira is Cloud Fortified, runs on Atlassian’s SOC 2 Type II / ISO 27001 platform, and the sprint-by-sprint planning record it leaves behind is exactly the kind of documentation program offices ask for later.

FAQ

How long does it take a government team to onboard to agile?
Plan on five sprints — roughly ten weeks with two-week sprints — before the team can commit and report defensibly. A velocity trend needs at least three completed sprints; treat anything earlier as a single data point.

What is the biggest mistake new government agile teams make?
Planning to the roster instead of to real availability — counting heads while ignoring allocation percentages, leave, holidays, and training. The second biggest: adopting another team’s velocity as a starting target.

Can a team with shared, part-time members run sprints at all?
Yes — shared staffing breaks sprint planning only when it is invisible. If each person’s allocation percentage is explicit and subtracted before the commitment, a 50% tester is simply 4.5 person-days in a nine-day sprint, not a surprise.

A practical way to start this week: create a one-page availability worksheet with four columns — name, allocation % to this team, days off this sprint, net person-days — and fill it in before your next planning meeting. Sprint 1 of the five starts there.

Try it: Install Sprint Planning with Capacity Planning for Jira free on the Atlassian Marketplace · Help docs

admin

See Full Bio