Short answer: for most public-sector teams, size the work in story points and size the capacity in person-days, then let past velocity connect the two. Use hours only for work that is genuinely fixed-effort, such as a scheduled data migration or a recurring compliance task.

Your program office wants a number it can put in a status report. Your contracting officer thinks in labor hours. Your team talks in points. Somewhere between the sprint board and the quarterly briefing, the translation goes wrong, and the team gets blamed for a forecast that was never solid. Choosing one estimation model on purpose, and pairing it with an honest capacity number, removes most of that friction.

Why does the estimation model matter more in government?

Budgets are fixed, fiscal-year deadlines do not move, and reporting runs up a chain of people who were not in the room. When staffing is flat or shrinking, “fewer people, same mission” becomes the planning reality, and a wrong estimate has less slack to hide in. An estimation model is really a promise about what you can explain later: how big was this work, how much time did the team have, and why did they commit to this much?

What are the real trade-offs between points and hours?

Hours feel precise and map neatly onto timesheets and labor categories. The trouble is that they invite false precision. A 13-hour estimate is read as a commitment, people pad privately, and the number drifts toward “hours I will be charged” instead of “effort this work needs.”

Story points measure relative size and absorb the fuzziness of unfamiliar work. Their weakness is that they mean nothing on their own. A point only becomes useful once you know how many your team completes in a sprint, and how many people-days were actually available when it did.

How do you choose and apply a model? Five steps

1. Decide what the number must answer. If leadership needs “will we finish by September 30,” you need a forecast, which points plus velocity handles well. If a contract bills strictly by effort, you may need hours for billing, even if planning uses points.
2. Estimate in one unit and report in another only through a stated ratio. Do not estimate each story twice. Pick one planning unit and convert at the report level.
3. Measure capacity in person-days, not headcount. Subtract federal holidays, leave, training, and the share of each person detailed to other programs.
4. Calibrate with three sprints of history. Divide points completed by person-days available to get points per person-day. Use the average, not the best sprint.
5. Write down the decision. Record the model, the ratio, and the reason. When staff or scope changes, you revisit a documented choice instead of an argument.

What does this look like with real numbers?

This is an illustrative example, not a customer case. A five-person team runs 10-day sprints. Over the last three sprints it completed 34, 28, and 31 points, with 50, 44, and 50 person-days available. That is 93 points over 144 person-days, or about 0.65 points per person-day.

Next sprint, one developer is out for two days and another has a one-day training course. Available capacity is 50 minus 3, so 47 person-days. The forecast is 47 × 0.65, or roughly 30 points. If someone proposes committing to 38 because the backlog looks urgent, the gap is visible and explainable: the team would need 0.81 points per person-day, about 25 percent above anything it has recently sustained.

If you must report hours, state the conversion once. At six focus hours per person-day, 47 person-days is 282 hours of capacity. Leadership gets a labor figure, and the team keeps planning in points.

How does one tool inside Jira make this repeatable?

The method above works in a spreadsheet, but spreadsheets drift away from the backlog. Someone updates the board, nobody updates the worksheet, and the ratio quietly goes stale. Doing the calculation inside Jira keeps capacity, allocation, days-off, and past velocity beside the issues you are about to commit. That is the idea behind Sprint planning with Capacity Planning for Jira: you plan sprints and team capacity on one screen using past velocity, days-off, and allocation, before you commit. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform, which suits agencies moving toward Atlassian Cloud and Atlassian Government Cloud (AGC).

It also leaves a plain planning record: who was allocated, which days off were subtracted, and why the team committed to N points. That is useful for decision-trail documentation. It is a planning aid, not a compliance product.

FAQ

Can we use both story points and hours?

Yes, but estimate in one unit and convert at the reporting layer using a fixed, documented ratio. Dual estimating doubles effort and produces two numbers that disagree.

What if our team is too new to have velocity?

Plan the first two or three sprints conservatively using person-days, treat the results as calibration, and avoid forecasting a full quarter until you have three sprints of data.

Do points work for fixed-price or fixed-hour contracts?

Often yes for planning, while billing stays in hours. Confirm the contract terms with your contracting officer, and keep the conversion ratio documented.

Try it: Install free from the Atlassian Marketplace · Read the help docs