Agile Release Planning

Schedule technique · See it on the map

Runnable here

Deciding which features ship in which release from a prioritized backlog and the team's known speed, not a fixed long-range schedule.

When to use it

Use it on a project where the team is delivering in short iterations against a backlog and scope is expected to change as feedback comes in — a product build where "what exactly release 3 contains" is meant to stay negotiable until close to release 3.

When to avoid it

Don't use it where a fixed external deadline requires a specific, contractually-defined scope on a specific date — a regulatory filing or a fixed-price deliverable needs a committed schedule, not a velocity-based forecast that moves as the team learns.

Steps

1. Prioritize the backlog so the highest-value, most-informative items are near the top.
2. Measure the team's velocity — how much backlog it clears per iteration — over several completed iterations, not just the first one.
3. Group backlog items into releases by walking down the prioritized list and filling each release to roughly the team's demonstrated velocity times the number of iterations before that release date.
4. Re-run the grouping at the start of each iteration as velocity is confirmed and the backlog is re-prioritized, rather than treating the first plan as final.

What it produces

• A release plan: which backlog items are targeted for which release, built from actual measured velocity and updated on a cadence rather than fixed once.

Common pitfalls

• Velocity from the first one or two iterations, which are usually depressed by ramp-up, gets used as the planning number for the whole project.
• A release plan built from velocity gets communicated externally as a fixed commitment, so the whole point of planning against actuals instead of a guess gets lost the moment it leaves the team.
• The backlog isn't re-prioritized between releases, so a release plan that made sense at kickoff ships stale, lower-value work while something more valuable waits its turn.

Worked example

A mobile expense-reporting app team clears roughly 30 story points per two-week sprint. With six sprints before the next quarterly release, they plan roughly 180 points of backlog into it, front-loading the highest-priority items — receipt photo capture and approval routing — and re-checking the plan each sprint as actual velocity comes in.

Where it comes from: this technique is named by the PMBOK Guide, 6th edition. No clause number is recorded for it here — a guessed citation would be worse than none. PMBOK-6 discusses release planning in its adaptive-environment narrative rather than defining it at a numbered tools-and-techniques clause.