For most public-sector delivery teams, story points are the better unit for sizing sprint work: they absorb the noise of individual estimates and pair naturally with velocity-based forecasting. Hours still matter — but for measuring team capacity, not for sizing backlog items. The practical answer is a hybrid: estimate work in points, plan capacity in person-days, and connect the two with your team’s own historical ratio.

Every agency agile adoption eventually hits this meeting. The branch chief asks the team to “just say how many hours the eligibility-rules rework will take.” The contracting officer’s representative nods along — invoices arrive in hours, so estimates should too. The scrum master explains relative sizing, and everyone leaves suspecting the other side’s numbers. The question sounds technical, but it is really about trust: which numbers can a government team stand behind when leadership asks?

Three forces make this debate sharper in government than in industry. First, the surrounding machinery speaks hours: task orders, earned-value reporting, and timekeeping systems all bill and account in them, so points can look “made up” by comparison. Second, estimates travel up a reporting chain and may be quoted back a year later, which raises the stakes of getting the unit wrong. Third, staffing reality: with hiring freezes and workforce reductions, “fewer people, same mission” is the operating condition, and teams cannot afford estimation ceremony that burns scarce staff time to produce false precision. An estimate of 14.5 hours is not more accurate than “about a 3-point story” — it is only more specific.

What’s the real difference between story points and hours?

Hours try to answer “how long will this take a specific person.” Points answer “how big is this compared with work we’ve already finished.” That difference is what matters for forecasting. Hour estimates fail for familiar reasons — individual variation, interruptions, optimism. Point estimates are wrong too, but wrong consistently, and consistent error is exactly what velocity math corrects for. If the team calls an item 5 points and history says it finishes about 25 points per sprint, the forecast holds even though nobody knows how many hours any single item took.

The corollary cuts both ways: points are meaningless without a velocity history, and hours are meaningless without honest time tracking — which, in practice, almost no team has.

When are hours still the right choice?

• Interrupt-driven queues. Help-desk and operations-and-maintenance work is better managed by item count and cycle time than by sizing; where effort must be reported, hours at the queue level are fine.
• Milestone-level contract reporting. A deliverable billed against an hourly task order can be tracked in hours at the milestone level while the team still runs points underneath it.
• Brand-new teams. A team with no shared delivery history has no reference class for relative sizing. Rough day-ranges for the first three or four sprints are an honest stepping stone; switch to points once a baseline exists.

For ongoing feature delivery by a stable team, points plus velocity produce better forecasts for less effort. The mistake is treating the choice as ideological rather than matching the unit to the work.

How do you choose? A four-step framework

1. Separate the two questions. The size of the work (points) and the time available to do it (person-days) are different measurements. Most estimation arguments happen because one number is being asked to do both jobs.
2. Match the unit to the work type. Feature backlog: story points. Interrupt-driven operations: item count and cycle time. Hourly-billed deliverables: hours at the milestone level only.
3. Connect points to time only at team level. Divide historical velocity by historical capacity in person-days to get a points-per-capacity-day ratio, and use it for forecasting. Never convert an individual’s points to hours or hand out per-person “point budgets” — that recreates hour tracking with extra steps and corrodes the estimates.
4. Record the basis of estimate. Write down who was allocated, which days off were subtracted, and why the team committed to N points. When an oversight question arrives months later, that short record — not the unit you chose — is what answers “who decided, and on what basis.”

A worked example: size in points, plan in person-days

Consider a six-person team maintaining a state eligibility system, running two-week sprints of ten working days. Raw capacity is 60 person-days. Subtract the knowns: one developer is detailed half-time to a data-migration program (−5), the team has three days of approved leave (−3), and two days of mandatory training land in the sprint (−2). Net capacity: 50 person-days.

Now the history. Over the last three sprints the team delivered 24 points on 46 person-days, 27 on 52, and 21 on 44 — roughly 0.5 points per person-day each time (0.52, 0.52, 0.48). Forecast for this sprint: 50 × 0.5 ≈ 25 points. The backlog owner is hoping for 30; the data says 25. And when the branch chief asks for hours, the team has a defensible answer in a currency everyone accepts: “We have fifty person-days of capacity, and our history says that yields about 25 points of work.”

No per-task hour estimates were needed, and the calculation takes minutes — provided the inputs are at hand.

How does one screen in Jira make this repeatable?

Where the hybrid model breaks down in practice is scattered inputs: velocity in a Jira report, leave in a shared calendar, allocation percentages in a spreadsheet someone updates monthly. Many agencies are consolidating exactly that scatter as they modernize planning into Atlassian Cloud — including Atlassian Government Cloud (AGC) for agencies that require it — and the same logic applies inside sprint planning. Sprint Planning with Capacity Planning for Jira puts past velocity, days off, and allocation next to the backlog, so the team sees capacity and forecast on one screen before it commits — and each sprint’s capacity math is there to look back on later. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform.

FAQ

Do auditors or oversight bodies require hour-based estimates?
No. Reviews look for a documented, defensible basis of estimate. A recorded capacity calculation plus a velocity history is exactly that — and often stronger than per-task hour guesses nobody can substantiate.

Can we convert story points to hours for contract reporting?
Only at team level, using your own history (for example, “about two person-days per point on this team”), and only as an approximation for planning conversations. Per-person or per-task conversion recreates the false precision points exist to avoid.

Should we re-estimate unfinished items in hours mid-sprint?
No. Track remaining work simply and let the sprint review capture what actually happened. With reduced staffing, re-estimation ceremony is capacity spent producing nothing.

A practical next step: pull your last three completed sprints, compute your points-per-capacity-day ratio, and test it against your next sprint plan before you commit.

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