TL;DR
- Agile release planning maps your backlog onto a timeline of sprints to forecast what you’ll ship and when — usually across 3–6 months or 3–12 sprints.
- Most software still ships late. Large IT projects run 45% over budget and 7% over time on average, and the cause is usually the plan, not the pace.
- Releases slip when a plan never locks six things: scope, capacity, dependencies, risk buffer, the quality gate, and stakeholder alignment — the Release Readiness Framework below.
- Shipping AI features adds three more checks: an evaluation gate, a token-cost forecast, and human-in-the-loop guardrails. That’s where our ADLC comes in.
- If your dates keep slipping despite the effort, the fix is usually the plan — or the team running it.
We at SumatoSoft have shipped 350+ custom projects since 2012, so we’ll be blunt about something the textbooks soften. A release plan is not a prediction. It’s a forecast you keep honest — the discipline that turns a roadmap into software shipped on time. Most guides explain the ceremony. Fewer explain why releases actually slip, when to bring in help, and what changes when the thing you’re shipping is an AI feature. This guide covers all three.
Why software projects miss deadlines (and what it costs)
Start with the uncomfortable data. McKinsey, with the University of Oxford, studied more than 5,400 IT projects. Large ones run 45% over budget and 7% over time on average, while delivering 56% less value than predicted — and software projects carry the highest risk of all. The longer a project runs, the worse it gets: every extra year adds about 15% to the overrun. The Standish Group’s long-running CHAOS research tells a similar story. Across software projects, only around a third fully succeed — on time, on budget, and as intended.
Here’s the part that matters. Releases rarely slip because a team codes too slowly. They slip because the plan was optimistic, the dependencies were invisible, or “done” was never defined. So slippage is a planning gap, not a speed problem — and release planning is how you close it.
What agile release planning actually is
Agile release planning maps your product backlog onto a timeline of sprints. It forecasts which features will be ready, and roughly when — usually across 3–6 months or 3–12 sprints. It sits between two other planning altitudes: the product roadmap above it (the why and the direction) and sprint planning below it (what the team builds next).
A release plan answers the question stakeholders care about most: when will we have it? It isn’t a contract — it’s a shared forecast you revise as you learn. The table below shows how the three altitudes differ.
| Product roadmap | Release planning | Sprint planning | |
|---|---|---|---|
| Horizon | Quarters to a year+ | 3–6 months / 3–12 sprints | One sprint (1–4 weeks) |
| Question it answers | Why, and in what direction? | What, and by when? (a forecast) | What next, and how? |
| Primary owner | Product leadership | Product Owner, team & stakeholders | The Scrum team |
| Main output | Strategic themes and goals | A release plan: scoped items, timeline, milestones, risks | A sprint backlog and sprint goal |
| Fixed or flexible | Directional; evolves | A forecast; adapts to learning | Committed for the sprint |
Is release planning part of Scrum?
Short answer: Scrum doesn’t prescribe release planning — and doesn’t prohibit it. The Scrum Guide lists five events, and release planning isn’t one of them. Its authors actually removed references to release planning and release burndowns in the 2011 update, on the logic that if every sprint produces a potentially shippable increment, you can release whenever it makes business sense. The 2020 Scrum Guide also renamed “ceremonies” to “events,” to signal these are working sessions with outputs, not rituals. Scrum.org treats release planning as an optional practice teams layer on top.
So why do most teams still do it? Because stakeholders need predictability, dependencies exist across teams, and budgets run on calendars. A forecast people can trust beats “sometime this year.”
The Release Readiness Framework — six checks before you commit to a date
After 350+ projects, we’ve found that releases slip for a small number of repeatable reasons. So before we commit to a date, we lock six things. We call it the Release Readiness Framework. Releases rarely slip because teams are too slow. They slip because the plan never locked scope, capacity, dependencies, risk, quality, and stakeholder alignment.
| Readiness check | The question to answer | If you skip it | The planning practice |
|---|---|---|---|
| Scope & priorities | What’s in this release, ranked by value? | Scope creep; the release never ends | A ranked, release-scoped backlog tied to clear release goals |
| Capacity & velocity | How much can the team actually deliver per sprint? | Optimistic dates; missed deadlines | A data-driven velocity and capacity forecast, not a wishful timeline |
| Dependencies | What outside this team must land first? | Blocked work; last-minute surprises | Map cross-team, API, vendor, and regulatory dependencies; sequence around them |
| Risk & buffer | What could go wrong, and where’s the slack? | No contingency; slip on the first surprise | Identify top risks, add buffer, and plan mitigations up front |
| Quality gate | What does “releasable” mean here? | Last-minute QA bugs and rework | Agree the definition of done and acceptance criteria before the build |
| Stakeholder alignment | Do business, delivery, and customers share one expectation? | Misaligned expectations; eroded trust | Align goals, dates, and trade-offs; revisit transparently when priorities change |
Each check is a question with a failure mode attached. Skip scope, and the release never ends. Leave capacity unchecked, and your dates are wishful. Miss a dependency, and a sister team blocks you in week six. The framework isn’t bureaucracy — it’s the shortlist of things that, left unlocked, turn a plan into a guess. And when you’re shipping AI features, the list grows by three, which we’ll come to below.
How to run release planning, step by step
The framework is what to lock. Here’s how to run the session that locks it.
- Review the ranked backlog. The product owner presents the release goals and a backlog ordered by value.
- Estimate the work. Size the items with the team — planning poker, t-shirt sizing, whatever you trust.
- Forecast with velocity. Use real historical velocity and current capacity, not a number you wish for.
- Set scope and milestones. Decide what fits, fix either the date or the scope (rarely both), and mark checkpoints.
- Surface risks and dependencies. Name what could go wrong and what must land first, then add buffer.
- Align stakeholders. Make sure business, delivery, and customers leave with one expectation.
Then keep it living. Revisit the plan at sprint boundaries and quarterly checkpoints, and adjust scope or date in the open when reality shifts. A plan you never revisit stops being a forecast and becomes a story.
Release planning in the age of AI
AI is changing both how we plan and what we plan. It helps to take those one at a time.
AI-augmented delivery — tighter forecasts, fewer unknowns
On the “how,” AI is moving fast. It already assists estimation, flags risk in a backlog, and automates the routine tracking and reporting that used to eat a project manager’s week. Gartner has predicted that 80% of today’s project-management tasks will be automated by 2030. Its 2025 survey of CIOs goes further: by 2030, they expect no IT work to be done without AI — 75% of it augmented, 25% fully automated. For release planning, the effect is real but bounded. Tighter estimates and fewer unknowns make forecasts more reliable. Still, AI can forecast and flag. It can’t decide what to ship, or align the people who depend on it. That judgment stays human.
Planning AI features — where ADLC comes in
On the “what,” shipping an AI feature changes the job. Shipping AI features breaks normal release planning: outputs are probabilistic, costs scale with use, and “done” means evaluated, not just tested. A login form behaves the same way every time; a language model does not. And this is about to be most teams’ problem, not a niche one — Gartner expects 40% of enterprise apps to embed task-specific AI agents by the end of 2026, up from under 5%. It’s also one reason enterprise AI so often stalls between pilot and production.
Planning an AI feature adds three checks to the six above. This is what our Agentic Development Lifecycle (ADLC) adds on top of a normal SDLC.
| AI-feature check | The question to answer | The ADLC practice |
|---|---|---|
| Evaluation gate | How good is good enough — and how do we measure it? | Define accuracy thresholds and an evaluation set; red-team before release. “Done” means evaluated, not just passing QA. |
| Token-cost forecast | What will this cost to run at scale? | Model token and inference cost per use as part of the plan, not a surprise after launch |
| Human-in-the-loop guardrails | What happens when the model is wrong? | Design oversight, fallback, and escalation into the workflow up front |
In practice, that means defining “good enough” and an evaluation set before you build, putting token cost in the plan rather than the post-mortem, and designing oversight for when the model is wrong. We build governed AI systems this way by default.
In-house vs. a delivery partner — when to bring in help
Sometimes the plan is sound and the team still misses. That usually points to something structural. A few honest signals it’s time to bring in help:
- Your dates slip the same way every release, even after the planning improves.
- You’re short on senior capacity, so estimates stay optimistic and review stays thin.
- Ownership is unclear, and no one is truly accountable for the forecast holding.
- You’re shipping your first serious AI feature with no evaluation or cost discipline in place.
None of these mean hire a vendor tomorrow. They mean the constraint is capacity, seniority, or process — not effort. When that’s the case, a partner who plans and delivers predictably becomes the rational call, whether that means restructuring how the work is staffed or adding a senior team that ships.
How SumatoSoft delivers software on time
The discipline above is how we work, not a theory. We start with discovery and business analysis so scope and success are clear before any code. Our defined development lifecycle runs Agile inside a structured SDLC, with ADLC layered on for AI builds. We agree the quality gate up front: the acceptance criteria the software must meet before release, written into the plan with you. And we re-plan in the open when priorities move. You can see projects we’ve shipped for how that plays out across 25+ countries.
Frequently asked questions
Is release planning part of Scrum?
No, and yes. Scrum doesn’t list release planning among its five events, and its authors removed it from the Scrum Guide in 2011. But Scrum doesn’t prohibit it, and most teams still plan releases for predictability, dependencies, and budgeting.
What’s the difference between release planning and sprint planning?
Sprint planning decides what the team builds in the next one to four weeks. Release planning forecasts what will ship across several sprints, usually three to six months. One is committed and tactical; the other is a flexible forecast.
Who is responsible for release planning?
It’s a team effort. The product owner leads on what to release and why, the team estimates and forecasts, and the Scrum Master facilitates. Stakeholders weigh in on priorities and dates.
How is release planning different for AI features?
Three ways. Output quality has to be evaluated, not just tested. Running cost scales with usage, so you forecast token cost as part of the plan. And you design human oversight for when the model is wrong. This is what an Agentic Development Lifecycle adds to a normal plan.
Can Kanban teams do release planning?
Yes. Kanban teams forecast releases using throughput and cycle time instead of sprint velocity. The goal is the same: a credible date for a scoped set of work.
How does release planning work across multiple teams?
You coordinate dependencies and sequence work across teams, usually with a shared planning checkpoint. The more teams and dependencies involved, the more the plan is about sequencing and less about any single backlog.
How does release planning connect to budgeting?
Closely. A release forecast becomes a cost and a timeline, which is what finance and sponsors actually approve. For AI features, the token-cost forecast belongs in that budget from the start.
How long should a release plan cover?
Usually three to six months, or about 3–12 sprints — shorter than a roadmap, longer than a sprint. Past six months, a plan is really a roadmap, and you should treat it as one.
Summary
Release planning is the discipline that turns a roadmap into software shipped on time. A release plan is not a prediction. It’s a forecast you keep honest. Lock the six readiness checks before you commit to a date, add three more for AI features, and revisit the plan as you learn. If your dates keep slipping, the constraint is usually the plan or the team — not the pace.
Book a delivery assessment
If releases keep landing late, we’ll help you find out why. Book a delivery assessment and we’ll map your roadmap and the real risks to your dates — including AI-feature risk — and tell you straight where the plan is exposed.
Sources, with dates: McKinsey & University of Oxford, “Delivering large-scale IT projects on time, on budget, and on value” (2012); The Standish Group, CHAOS Report (2020); Scrum.org and the Scrum Guide (2011 and 2020 editions) on release planning and events; Gartner on AI in IT work (CIO survey, November 2025) and task-specific AI agents in enterprise apps (August 2025); Gartner’s prediction on the automation of project-management tasks by 2030. Figures are attributed to their original sources; predictions are labelled as predictions.
Let’s start
If you have any questions, email us info@sumatosoft.com
