Short answer: The first five sprints should teach a new government team one habit: commit only to what real, measured capacity supports. Set a short working agreement in sprint one, record available days every sprint, and let completed work, not optimism, set each next commitment.

Picture a new product team at a state agency. They are modernizing an eligibility intake process, the go-live is tied to the start of the next fiscal year, and on day one a deputy director asks, “So when will it be done?” The team has no history, half the members are shared with other programs, and the agency is doing the same work with fewer people than last year. That is the normal starting point for agile in the public sector, and it is where the first five sprints either build trust or burn it.

Why do the first five sprints matter so much in government?

Government teams are rarely allowed to fail quietly. A missed commitment travels up a chain of oversight, gets compared with a fixed budget, and is remembered at the next funding conversation. Early sprints set the pattern that leadership uses to judge agile for years. When budgets are flat and staffing is shrinking, “fewer people, same mission” makes it worse: every lost person-day has to be visible before the team commits, not discovered afterward.

How do you run the first five sprints?

Treat the five sprints as a ramp, each with one learning goal.

1. Sprint 1: Establish the baseline. Agree on sprint length (two weeks works for most agencies), a definition of done, and who is on the team at what allocation. Commit deliberately small. Record every person’s available days, including holidays, training, leave, and time owed to other programs.
2. Sprint 2: Compare plan to reality. Hold the first honest retrospective on one question: what did we commit to, what did we finish, and which absent days did we fail to count? Do not chase speed yet.
3. Sprint 3: Start using history. With two sprints of data, calculate completed points per available person-day. Use it to size the next commitment instead of gut feel.
4. Sprint 4: Make capacity visible to stakeholders. Share a one-page view: available days, past completed work, and the resulting commitment. This is the moment leaders begin to trust the number.
5. Sprint 5: Forecast and decide. With four sprints of history, give a range for the next release rather than a single date, and name which scope is first to move if capacity drops.

What should be in place before sprint one?

• A working agreement covering sprint length, ceremonies, and how mid-sprint requests are handled.
• A named product owner with authority to order the backlog.
• A list of shared or part-time team members with their agreed allocation percentages in writing.
• A calendar of known days off, agency-wide training, and holidays across at least the next three sprints.

How do you calculate capacity in the early sprints?

Start from person-days, not hours or optimism. Multiply team members by sprint working days, then subtract holidays, leave, training, and the share of anyone allocated elsewhere. The result is your available days. Once you have completed work from earlier sprints, divide it by the available days that produced it to get a points-per-available-day rate.

Illustrative example (hypothetical numbers): a six-person team runs ten-day sprints. Over sprints 1 to 3 it completed 18, 24, and 27 points, with 38, 44, and 47 available person-days respectively. That is 69 points over 129 days, or about 0.53 points per available day. For sprint 4, the team has 60 raw person-days. One agency-wide training day removes 6, planned leave removes 8, and one member allocated at 50% to another program removes 5. That leaves 41 available days, so a capacity-based commitment is about 22 points (41 × 0.53). A team that simply repeated “last sprint’s 27” would have over-committed by roughly 5 points before the sprint started, which is exactly the surprise that damages early credibility.

How does doing this in one tool make it repeatable?

Teams that start in spreadsheets tend to abandon them around sprint three, when the calendar gets messy and the numbers drift from the backlog. Moving this inside Jira, as agencies move to Atlassian Cloud and Atlassian Government Cloud (AGC), keeps the plan next to the work. Sprint planning with Capacity Planning for Jira shows sprint scope and team capacity on one screen in the backlog, using past velocity, days off, and allocation before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. It records who was allocated, which days were subtracted, and why the team committed to N points, which gives a PMO a simple decision trail without a separate document to maintain. It is a planning tool, not a compliance product.

A practical 90-day rollout idea: use sprints 1 to 2 to enter the team, allocations, and days off; sprints 3 to 4 to commit from capacity and compare; sprint 5 to review the trend with leadership.

FAQ

How long should sprints be for a team new to agile in government?
Two weeks is a common starting point. It is short enough to correct course quickly and long enough to finish meaningful work around meetings and approvals.

When does velocity become reliable enough to forecast with?
There is no fixed rule, but three to four sprints of consistent data usually allow a range-based forecast. Always adjust for the available days in the upcoming sprint.

What if team members are shared with other programs?
Agree on allocation percentages up front and record them. Subtract the unavailable share from capacity every sprint instead of assuming full-time availability.

Try it: Install free on the Atlassian Marketplace · Help docs