Short answer: estimate at three levels, not one. Use coarse points for epics, refined points for stories, and hours only for subtasks, then check the total against real sprint capacity before you promise a date.

A county benefits office sizes an epic at “about 55 points” in January. By March, the same epic has been split into stories that add up to 71. Nobody lied, and nobody was careless. The epic estimate was a guess made before the work was understood, and it was reported upward as if it were a plan. With flat budgets and fewer people, that gap now lands directly on a fixed fiscal-year deadline.

Why does epic-level estimation drift in government?

Epics are written early, often during funding or approval cycles, when the team knows the least. Those numbers then travel into status decks and budget justifications. When refinement reveals the real size, the team looks like it slipped, even though the estimate was never precise. The fix is not better guessing. It is treating each level of the backlog as a different kind of estimate with a different job.

How do you right-size work from epic to subtask?

Use this four-step framework. Each step narrows the estimate and makes it safer to commit.

1. Size epics coarsely, and label them as ranges. Record an epic as 40–70 points, not 55. A range tells leadership the estimate is early. Narrow it only after stories are refined.
2. Split epics into stories that fit one sprint. If a story cannot finish inside a sprint by one or two people, it is still an epic. A useful test: no story larger than about a third of your average velocity.
3. Estimate stories in points with the whole team. Compare against a small set of reference stories the team already finished. Relative sizing is faster and less contentious than hours at this level.
4. Break committed stories into subtasks in hours. Do this at or just before sprint planning, not months earlier. Keep subtasks between roughly 2 and 8 hours. Anything longer hides risk; anything shorter creates tracking overhead.

Two rules keep the levels honest. First, never add up subtask hours and convert them back into epic points. Second, re-total the epic after every refinement session and record the change with a note on why it moved. That note becomes part of your decision trail: a plain record of what was known, when, and what changed.

How do you turn a refined backlog into a date?

Divide remaining story points by capacity-adjusted velocity, not raw velocity. Raw velocity assumes a full-strength sprint that rarely happens in agencies with holidays, training days, and detailed staff.

Worked example: the 55-point epic that became 71

A team of five developers plans a “renewal reminders” epic. Assume the following inputs:

• Early epic estimate: 55 points. After refinement into 8 stories: 71 points (+29%).
• Last three sprints delivered 30, 34, and 32 points, an average velocity of 32, all at full strength.
• Next sprint: 5 developers × 10 working days = 50 person-days. Subtract 4 PTO days and 1 federal holiday for all five people (5 days) = 9 days off, leaving 41 available days, or 82%.

Capacity-adjusted forecast for the next sprint: 32 × 41/50 = 26.2, so plan about 26 points.

The naive date math (55 ÷ 32) says 1.7 sprints. The right-sized math (71 ÷ 26) says 2.7 sprints. That is a full extra sprint, and it is visible in February instead of discovered in April. Even at a full-strength 32 points, 71 points needs 2.2 sprints, so the size growth alone matters. The team can now choose to cut scope, add a sprint, or negotiate the date while there is still room to decide.

How does doing this in one tool make it repeatable?

The framework fails when the pieces live in different places: epic sizes in a slide, velocity in a spreadsheet, days-off in a shared calendar. Every planning session then starts with reconciling files. Keeping backlog hierarchy, past velocity, days-off, and allocation on one screen inside the Jira backlog means the capacity-adjusted number above is calculated the same way every sprint, by anyone on the team. That is what Sprint planning with Capacity Planning for Jira does: you plan sprints and team capacity together, 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 platform, which matters for agencies moving planning work off spreadsheets and toward Atlassian Cloud, including Atlassian Government Cloud (AGC). The app records planning decisions; it does not replace your agency’s compliance processes.

For a practical start, try a 90-day rollout: in month one, re-estimate only your top three epics as ranges; in month two, split them into sprint-sized stories; in month three, forecast dates with capacity-adjusted velocity and compare to actuals.

FAQ

Should government teams estimate in story points or hours?

Use points for epics and stories, where relative sizing is faster and less falsely precise, and hours only for subtasks within a committed sprint.

How big should a user story be?

Small enough to finish within one sprint. A practical ceiling is about one third of average velocity, so a team averaging 32 points should split stories above roughly 10.

What do we tell leadership when an epic estimate grows?

Show the original range, the refined total, and the reason it changed. Growth during refinement is normal; unexplained growth is what erodes trust.

Try it: Install free · Help docs