How to put together a quarterly roadmap

Count delivery weeks before opening the backlog

Write down the first and last working day.

Thirteen calendar weeks is sixty-five working days per person. Subtract public holidays, booked leave, on-call rotations, the mandatory training week, any release freeze, and then the final week of the quarter, because a roadmap that plans work into its last days has no room to close. Multiply what remains by headcount. Nine and a half weeks across six people is fifty-seven person-weeks, not the seventy-eight the calendar implies, and that gap is where most over-committed quarters begin. Do this first, or the calendar becomes something you negotiate with after you have promised.

Create Tech Debt and Bug Budget first

Both exist before you write a single feature epic, each with a named owner and a share of the person-weeks you just counted.

Ten per cent each is a workable opening split. Then correct it with last quarter's actuals rather than last quarter's intentions: if bug work burned eighteen per cent, budget eighteen. Every bug raised and every debt item found this quarter links to one of these two epics. Nothing floats unbucketed. By week six the burn rate against each budget tells you whether quality is improving or rotting, and it is the only quality trend you get without building anything.

Bring forward committed outcomes and cap them

List every outcome in Committed or Working On with its currency target and the value already claimed by epics that closed in earlier quarters. Target minus claimed is the remainder, and write that number beside each outcome, because the remainder is what this quarter's epics have to cover, not the headline target. Anything in Idea or Exploring gets no roadmap space until it has been shaped, priced and committed. Then cap it at three or four live outcomes per team. Past that the epics compete for the same people and the quarter ends with four things at eighty per cent and nothing validated.

Write the epics and show the pricing arithmetic

For each outcome, write the epics that move it this quarter.

One outcome each, one roadmap each, and a planned contribution in pounds with the sum written out on the ticket. Not "improves retention" but "1,200 failed renewals a year, 18 per cent recoverable, £1,900 average contract, so £410k". Name each input's source and who owns that number. If an epic will not finish inside the quarter, split it into a piece that ships now and a piece that goes on the next roadmap, each carrying its own share of the value. An epic that resists that split usually means the outcome under it was never shaped.

Sum against the remainder, then add calibration headroom

Add each outcome's epic values and compare the total to the remainder from step three.

Then divide the remainder by your realised-versus-planned ratio from the last four quarters of outcome validation. At 70 per cent realisation a £750k remainder needs roughly £1.07m of planned epics behind it. If your epics total £910k, the finding is a £160k gap that someone names before the quarter opens, or the team says out loud that the outcome will not close this quarter. Use your own history, not an industry figure. With no history, plan uncalibrated and record realised against planned so the next quarter has something to work from.

Sequence for dependencies, not for enthusiasm

Put the epics on weeks.

For each one, write down what it needs that the team does not control: another team's API, a vendor contract, a security or legal review, a data migration, one named specialist. Every external dependency gets raised as an issue with an owner and a date in the previous quarter, not discovered in week two of this one. Then check that nothing critical lands in the freeze week and that no two epics need the same specialist in the same fortnight. Sequencing is what turns a list that adds up on paper into a plan that runs.

Forecast the whole set, not the loudest epic

Size the epics, then simulate the entire roadmap against your own throughput, sampling completed items weekly from the last eight to twelve weeks, and take p50 and p85 completion dates for the set. Do not forecast epics one at a time and add the dates together: four confident epics all landing in the same fortnight is where plans die, and only a whole-set simulation shows it. If your history is shorter than eight weeks, or the team changed size, say the forecast is unreliable and re-run it at the end of week three rather than publishing a number you do not believe.

Cut whole epics until p85 fits, then publish

Reduce until the whole set lands inside the quarter at p85, not p50.

Cut whole epics rather than shaving scope off all of them: a half-built epic delivers none of its planned value, a deferred one delivers all of it next quarter. Do not cut tech debt or the bug budget, that reflex is what the fixtures exist to stop. Publish where the business reads it, not only in the delivery tool: outcomes, the epics under each, currency planned, gate status, and the cut list with the pounds each cut epic carried. The cut list is the part teams skip and the part that protects them in month three.

Gate the first six weeks, book the close

An epic does not open the quarter until it has product approval, engineering approval and, on an AI-augmented team, at least one product-approved story attached. On an AI-native team the same two approvals apply, with the key user journeys and the test requirements written on the ticket in place of the child story. Work backwards: research and design for those epics happens in the previous quarter. Expect four to six weeks gated on day one and the rest still in research; a fully gated roadmap usually means the later epics were written thin. Last, put the monthly outcome validation dates and the close date in the calendar with owners.