Right-sizing a government backlog means breaking every epic into stories that fit inside roughly one sprint, then breaking the stories you’re about to commit to into hour-level subtasks you can check against your team’s real net capacity — not the epic’s original rough-cut estimate. Skip that step and you get what most government PMOs already know too well: an epic that’s been “90% done” for three status reports in a row, because nobody ever cut it down to a size where “done” was measurable.

Why oversized epics are a bigger problem in government

In a commercial startup, an epic that balloons costs a sprint or two of frustration. In a government program, it costs a line in a steering committee deck, an uncomfortable conversation with a program executive, and sometimes a mid-fiscal-year funding request that procurement never planned for. Fixed budgets and fixed fiscal-year deadlines don’t leave much room for “we’ll know more next sprint.” And with headcount flat or shrinking across FedCiv, DoD, and state agencies, teams have less slack to absorb an epic that turns out to be three times its original guess. When leadership asks whether a program is on track, the honest answer depends entirely on whether the epic was ever broken down small enough to measure in the first place.

A five-step framework for right-sizing backlog work

Most backlogs don’t need a new methodology — they need a consistent habit applied every sprint. Five steps cover it:

1. Anchor the epic to one outcome and acceptance criteria. Before splitting anything, write down what “done” means in a sentence a program executive would accept. An epic without a testable outcome gets broken down arbitrarily and reassembles into the same fog it started as.
2. Decompose into sprint-sized stories. Use INVEST — independent, negotiable, valuable, estimable, small, testable — as the filter. A story that can’t be finished by one team inside a single sprint isn’t a story yet; it’s a smaller epic wearing a story’s name tag.
3. Check story sizes against trailing velocity. If the last three sprints averaged 30 points, a 21-point story is effectively a sprint by itself. That’s a signal to split further, not a badge of ambition.
4. Break next-sprint stories into hour-level subtasks. Points are useful for backlog-level forecasting; hours are what a scrum master needs to check one specific sprint against one specific team’s specific availability.
5. Reconcile subtask hours against net capacity before committing. Net capacity means gross hours minus PTO, training, details to other duties, and meeting load — not the calendar math everyone wishes were true.

A worked example: migrating a benefits-intake epic

Say a state health-and-human-services program logs “Redesign Online Benefits Intake” as a single epic with a placeholder estimate of “13 sprints.” That’s not a plan; it’s a shrug. Broken down with INVEST, it becomes five stories:

• Design the new intake form UI — 8 points
• Integrate the eligibility rules engine — 13 points
• Migrate existing applicant records — 21 points
• Add document upload with virus scanning — 13 points
• Accessibility and plain-language review — 5 points

That’s 60 points total. Against a trailing velocity of 32 points per sprint, the epic now forecasts to roughly two sprints — a number a PMO can actually put in a status report, and defend if asked.

The 21-point migration story is still large relative to a 32-point sprint, so before committing it, the team breaks it into subtasks: build the extraction script (16 hours), data mapping and cleansing (24 hours), a migration dry run with validation (20 hours), and cutover with a rollback plan (12 hours) — 72 hours total.

The team has 5 developers, a 10-day sprint, and roughly 6 focus hours per person per day, for 300 gross hours. Subtract 18 hours for one developer’s mandatory training and 12 hours for another’s approved leave, and net capacity comes to 270 hours. The migration story’s 72 hours is about a quarter of that sprint — comfortably plannable alongside the sprint’s other committed work, instead of discovered mid-sprint as the thing that quietly ate the whole team.

Doing this on one screen instead of across three tools

Right-sizing only holds up if the story-level estimate and the subtask-level hour math live somewhere the person running sprint planning can see side by side with who’s on leave and who’s already over-allocated. Agencies still tracking velocity in one spreadsheet, days-off in an Outlook calendar, and the backlog in Jira end up redoing this reconciliation by hand every sprint — a fragile process that rarely survives staff turnover. Sprint Planning with Capacity Planning for Jira keeps epic breakdown, past velocity, days-off, and team allocation on one screen inside the Jira backlog you already use, so a scrum master sees the story-level forecast and the subtask-level capacity check before committing to a sprint, not after. It also leaves a plain record of how each commitment was built — which stories, which subtasks, whose hours were counted and whose were subtracted for leave — useful whenever someone up the chain asks how a number was reached. That consolidation is the same direction Atlassian is pushing public-sector programs generally: fewer disconnected spreadsheets, more planning inside Atlassian Government Cloud. The app itself is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

How big should a government agile story be?
Small enough for one team to finish inside a single sprint with room to spare. As a rule of thumb, if a story alone would consume more than half the team’s sprint capacity, split it further before sprint planning — not during.

What’s the difference between right-sizing at the story level and the subtask level?
Story points forecast the backlog — how many sprints an epic will likely take based on trailing velocity. Hour-level subtasks check one specific sprint — whether the stories about to be committed actually fit the team’s net capacity once days-off and allocation are subtracted.

How often should an epic be re-decomposed?
Any time its estimate moves significantly, and at minimum every time it’s about to feed a new sprint. An epic sized once at kickoff and never revisited is usually the one still showing “90% done” two quarters later.

Try it: Install free · Help docs