Release Planning and Increment Delivery
3
Levels
Product roadmap, release plan, sprint plan
MVP
First Release
Minimum viable or minimum business increment
2
Release Modes
Fixed date or fixed scope
three horizons · different cadence, different owner
Planning Horizons
how to read this
- › Roadmap (top) sets direction for quarters or years. Owned by the product side.
- › Releases (middle) are the next deliverables. Each is 4–12 weeks of committed work.
- › Sprints (bottom) are what the dev team actually commits to right now. 1–4 weeks each.
- › Each level has a different owner and cadence. Mixing them up is how teams end up with roadmap commitments no sprint can deliver.
Deploy ≠ Release
deploy · technical
Code → production
The build lands on servers. Users still can't see it behind a feature toggle.
release · business
Exposed to users
The feature toggle flips on. Marketing announces. Risk is user-visible now.
Exam Traps
Deployment is not release
Deployment pushes code to production. Release exposes it to users. Feature toggles let you deploy without releasing.
Fixed date forces scope cuts
If the date is fixed, you cut the least valuable work to meet it. MoSCoW prioritization makes this possible.
MBI is smaller than MVP in many contexts
Minimum Business Increment is the smallest slice that delivers real value. Use it when MVP feels too large.
Deploy ≠ release
Feature toggles let you deploy code safely and release it later when the business is ready.
Do not fix both
You cannot fix date AND scope. Pick one. The other must flex.
The menu evolves over months. Seasonal dishes, new techniques. That is the product roadmap.
The opening night menu. Fixed set of dishes. That is the release plan.
What the kitchen preps today for tonight. That is the sprint plan.
The dishes can be plated and hidden in the kitchen. They are not "released" until a customer orders them.
Ready to test your PMP knowledge?
1,800 practice questions written by certified professionals.
Start Practicing PMP