Most government agile teams get the best results by defaulting to story points for sprint-level estimation and reserving hours for contract- and audit-level reporting — converting between the two only at the reporting layer, never at the planning layer. That distinction sounds academic right up until a contracting officer asks a scrum master “how many hours will this feature take,” and the honest agile answer — “we don’t estimate individual tasks in hours” — is true and satisfies no one, because the contract runs on hours and the monthly status report runs on timesheets.

Why this question keeps coming up in agencies

Most government PMOs grew up on hour-based, task-level planning: work breakdown structures, labor categories, earned-value tracking. Agile methodology asks teams to estimate in relative units instead — story points or ideal days — because individual hour estimates vary wildly by who does the work and create a false precision teams then get held to. But the reporting structure around the team rarely changes at the same pace as the team’s own process. Contract deliverables, invoicing, and program-office dashboards still expect hours. Teams that pick one model and ignore the other end up in one of two bad places: all points, and nobody above the team can translate a sprint commitment into anything a contracting officer can check against an invoice; or all hours, which quietly reintroduces the estimation problems agile was meant to solve — padded estimates, individual blame for missed hours, and a backlog that takes forever to size because every item needs a hallway negotiation.

What each unit is actually built for

Story points size work relative to other work, using a team’s own reference stories, and they only become useful in aggregate — as velocity, tracked sprint over sprint. They stay stable for a given team even when the specific people doing the work change week to week, which is exactly the situation in most agencies with contractor rotation and shared staff. Hours size an individual’s task against their own calendar. They’re precise for one person doing one known task, and unreliable as a forecasting tool once you’re averaging across a backlog of unlike work, because every hour estimate is really a guess about who will do it and how experienced they are.

The practical rule: use points where you’re forecasting what a team can deliver across sprints. Use hours where you’re accounting for a specific person’s time against a funded task or contract line.

A five-step framework for choosing (or blending) both

1. Size backlog items in story points against two or three reference stories the whole team agrees on at kickoff — write them down, since a rotating contractor roster is the fastest way to lose a shared sense of what a “3” means.
2. Track velocity in points per sprint for at least three sprints before treating it as a forecasting baseline. One good or bad sprint isn’t a trend.
3. Build capacity for the next sprint in person-days, accounting for days off, part-time allocation to the program, training, and anyone detailed elsewhere.
4. Convert that capacity into an expected point commitment using the team’s own points-per-person-day ratio from recent history — not a generic rule of thumb from a blog post.
5. Convert committed points into hours only at the reporting boundary — for a contracting officer, program office, or earned-value report — using the team’s own historical hours-logged-per-point ratio. Keep that ratio visible and recheck it quarterly so it doesn’t quietly go stale.

How do you convert story points to hours for a government status report?

Take a six-person development team on a two-week (10-working-day) sprint. Over the last quarter, when the team was fully staffed — 60 person-days available — average velocity was 42 points, a ratio of 0.7 points per person-day. This sprint, capacity is lower: two members are only half-time on this program, one is out three days for required training, and a recently onboarded contractor is running at roughly 60% effective while ramping up. That works out to 53 available person-days instead of 60, or 88% of full capacity. Applying the team’s own 0.7-points-per-day ratio gives a realistic commitment of about 37 points — not last quarter’s average of 42 — and 37 is the number the team should defend in sprint planning. For the monthly contract status report, the team’s own logged-hours-per-point ratio (say, 6.5 hours per point, calculated from its own timesheets against delivered points) turns that 37-point commitment into roughly 240 hours — a figure the contracting officer can reconcile against invoiced labor, without the team ever estimating a single backlog item in hours.

Doing this on one screen, inside Jira

The math above is straightforward on paper and hard to keep consistent in a spreadsheet once days-off, part-time allocation, and contractor turnover multiply across sprints and programs — one more reason agencies modernizing off spreadsheets or Data Center are moving this kind of planning onto Atlassian Cloud, including Atlassian Government Cloud. Sprint planning with Capacity Planning for Jira puts velocity history, days-off, and individual allocation on the same screen as the backlog, so the points-per-person-day ratio in the example above is a number the tool maintains automatically rather than a spreadsheet formula someone has to remember to update every sprint. It won’t file the contract status report, but it keeps the planning-layer math (points, capacity) and the reporting-layer math (hours, ratios) traceable back to the same sprint and the same decisions — which matters the day a program office or auditor asks how a commitment number was reached. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001-certified platform.

With fewer staff and flatter budgets across FedCiv, DoD, and state and local programs this year, knowing your team’s actual points-per-day ratio — instead of assuming last year’s — matters more, not less.

A quick way to start without any tool at all: pull your last three sprints’ logged hours and delivered points, divide one by the other, and that’s your own conversion ratio.

FAQ

Should a government agile team ever estimate entirely in hours?

For short, well-understood work — a configuration change, a known bug fix — hour estimates are fine. For forecasting a varied backlog across sprints, points hold up better because they’re relative and don’t need re-baselining every time staffing or scope shifts.

How often should the points-to-hours conversion ratio be updated?

Recalculate it quarterly, or immediately after a significant staffing change such as a new contractor rotation or a team split. A ratio from a fully staffed quarter two years ago will misstate today’s hours.

What if the program office insists on hour-based estimates for every backlog item?

Estimate in points internally and publish an hours conversion for external reporting only. That split is exactly what this framework is for — the team’s planning process doesn’t have to match the format the oversight chain requires.

Try it: Install free · Help docs

Part of the DiViM series on sprint and capacity planning for government agile teams. Browse the full hub.