Right-sizing a government backlog means decomposing each epic into vertically sliced stories that one team can finish inside a single sprint — as a working rule, no story larger than about a third of trailing velocity — and then breaking only the next sprint’s stories into hour-level subtasks you reconcile against net capacity before committing. Anything bigger stays an epic; anything not yet scheduled stays at the story level until planning.

Here is the situation that makes this urgent right now. A team of six lost two positions to a workforce reduction in the spring. The backlog, estimated in January by the January team, still says the modernization epic is “about four sprints.” Nobody has re-cut it. The program schedule briefed up the chain is built on numbers that describe a team that no longer exists. Fewer people, same mission — which means knowing the real size of the work before committing matters more than it did last year, not less.

Why oversized backlog items hurt government programs most

An epic that was never properly decomposed fails quietly. It sits at “in progress” across three reporting cycles, absorbs whoever is available, and only reveals its true size when a fiscal-year deadline makes the gap impossible to ignore. In a commercial team that is an annoyance; in a program office with a fixed budget, an oversight committee, and an end-of-September delivery date, it is a schedule variance someone has to explain in writing. And when estimates go stale after a staffing change, every downstream number — sprint forecasts, quarterly roadmaps, contract burn projections — inherits the error.

How do you break an epic down to sprint-ready stories?

Treat decomposition as three separate passes, done at different times, rather than one heroic backlog-grooming marathon.

1. Pass 1 — slice by releasable value, not by architecture layer. Split the epic into vertical slices a user or auditor could actually see working: “schedule an inspection from a mobile device,” not “build the API layer.” Horizontal slices (database work, then services, then UI) look tidy but produce nothing demonstrable until the very end — the worst possible shape for a program that reports progress quarterly.
2. Pass 2 — apply a sizing band against trailing velocity. Compare each story to what the team actually finishes per sprint today, not at kickoff. If trailing velocity is 21 points, a 13-point story is more than half a sprint riding on one item — split it before it enters planning. The one-third rule is a guardrail, not a law, but every exception should be a decision someone made on purpose.
3. Pass 3 — subtask only the next sprint’s stories, in hours. Subtasking the whole backlog is wasted motion; requirements will shift before you get there. The stories about to be committed are the ones that need hour-level subtasks, because hours are what you can check against this team’s availability in this sprint.

Between pass 2 and pass 3, hold stories to a short definition of ready: a testable acceptance criterion, no unresolved dependency on another team, and an estimate the people doing the work agreed to. A story that fails any of these is not ready to be committed, no matter how urgent it feels.

What does right-sizing look like in practice?

A transportation agency team is digitizing field-inspection scheduling. The epic arrives as one line: “Digitize Field Inspection Scheduling,” gut-estimated months ago at “a quarter, maybe.” Pass 1 produces five vertical slices: mobile scheduling screen (5 points), inspector route optimization (13), offline access with sync (13), legacy calendar import (8), and a security and Section 508 review (3) — 42 points total.

The team’s trailing velocity is 21 points per sprint — down from 28 before it shrank from six to four. Forecast: 42 ÷ 21 = two sprints of focused work, a number the PMO can put in a status report and defend. Pass 2 flags both 13-point stories as larger than a third of velocity; offline sync splits into cached read-only access (8) and queued offline writes (5).

Before planning the first sprint, pass 3 turns the committed stories into hour-level subtasks totaling 118 hours. Now the capacity check: the two-week sprint contains a federal holiday, leaving nine working days. Four developers at roughly 5.5 focus hours a day gives 198 gross hours. One developer is detailed half-time to another program (−50 hours); another has two days of approved leave (−11). Net capacity: 137 hours. The 118 committed hours fit with about a 14% buffer — a commitment made with evidence, not optimism. Run the same math against the January staffing assumptions and the team would have committed to work it had no chance of finishing.

Why this works better on one screen inside Jira

The weak point in this whole discipline is that the pieces usually live in different places: points in the backlog, velocity in a report, leave in a shared calendar, allocation in someone’s head. Every sprint, someone reassembles the picture by hand — and the reassembly is the first thing skipped under deadline pressure. Sprint Planning with Capacity Planning for Jira puts past velocity, days-off, and allocation next to the backlog on one screen, so the pass-3 reconciliation happens where the commitment is made, before it is made. It also leaves a plain record of what was counted and what was subtracted when the team committed — the kind of decision trail that answers “why did you commit to 26 points?” months later without archaeology. For agencies consolidating tools as part of a move to Atlassian Cloud or Atlassian Government Cloud, that is one more spreadsheet retired. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform.

A practical first step: book 30 minutes this week, pick your single largest in-progress epic, and run passes 1 and 2 against your current — not kickoff — velocity. If the forecast moves by more than a sprint, the rest of the backlog needs the same treatment.

FAQ

What is the right size for an epic, a story, and a subtask?
An epic spans multiple sprints and is estimated roughly, for forecasting. A story fits inside one sprint — ideally no more than about a third of trailing velocity. A subtask is hour-level work, created only for stories entering the next sprint.

Should government teams estimate epics in points or hours?
Both, at different stages. Points against trailing velocity forecast how many sprints an epic needs; hours at the subtask level verify that a specific sprint’s commitment fits a specific team’s net capacity after leave, holidays, and allocation are subtracted.

How should we re-size the backlog after losing team members?
Re-baseline velocity from the sprints completed with the new roster — even if that is only two or three data points — and re-run every active epic’s forecast against it. Estimates made by a larger team describe that team, not yours.

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