Agile release planning is based on fixed-length, normed-capacity cycles that operate on dynamically-planned and dynamically-scoped features. In Scrum, fixed-date release planning must be handled by controlling scope to meet the deadlines, as you cannot have both fixed-date and fixed-scope deadlines simultaneously. This is rarely a practical problem, but can be a political one in non-agile shops.
How to Perform Agile Release Planning
Agile release planning is based on iterations. In order to do calendar- or time-based release planning in Scrum:
- The entire Product Backlog is given a rough estimate, usually at the level of epics rather than detailed user stories.
- A fixed Sprint length is determined. 2-4 weeks are common values; this length should not change during the lifecycle of the project without recalculating Sprint capacity and adjusting release schedules.
- A velocity is calculated based on the team's past performance, or on an "educated guess" if no past performance is yet available.
- A fudge factor for the cone of uncertainty is applied. This is commonly 0.6 for new teams or for projects with large cones of uncertainty during initial project planning, but fudge factors are inherently variable and can be adjusted to fit currently-available knowledge about the problem domain, the team, and available resources.
- A planning velocity is calculated, e.g.
estimated velocity * fudge factor.
Number of iterations for a release are calculated using the following variables and formula:
- e = aggregate estimate of all Product Backlog Items
- v = planning velocity
- i = estimated iterations for release, rounded up to nearest whole number
e / v = i
The i value can be turned back into a calendar or time estimate by multiplying interations by the length of the Sprints in weeks or months, e.g.
i * 2.
A Worked Example
Let's say you have a total backlog of 200 story points, and plan to use a two-week Sprint length. Your team's historical velocity is 20, but this is a brand-new project with a large cone of uncertainty, so your fudge factor is the standard 0.6 multiplier; as a result, your planning velocity is 12 story points per Sprint after applying the fudge factor.
So, your release plan for all of the Product Backlog Items would be:
200 / 12 = 17 Sprints
You then turn this into a calendar or time estimate with:
17 * 2 = 34 weeks
Based on this information, your project schedule will state that it will take approximately 34 weeks to ship all the features currently in the Product Backlog. This is an estimate based on the information currently available, and should be treated as a planning value rather than an ironclad guarantee.
Adjust Scope During Inspect-and-Adapt Inflection Points
As the project progresses, the cone of uncertainty narrows and the team can make more accurate estimates about the amount of remaining work on the Product Backlog. In addition, a properly-functioning Scrum team will become more accurate about measuring its velocity as the project continues, so the release-schedule calculations should be redone from time to time to "true up" the schedule based on more accurate data as it becomes available.
In addition, the Product Owner may add or remove scope (in the form of Product Backlog Items) throughout the project. This will expand or reduce the scope of the project, and will obviously impact the estimated schedule. Changing project scope should generally trigger a recalculation of the release date when that happens.
Finally, Scrum strives to provide a potentially-shippable product at the end of each and every Sprint. While it may not be feature-complete in the sense that it contains 100% of all backlog items, the product should be a stable and releasable state during Sprint Review so that the organization can choose to ship earlier if sufficient value is present in the product to justify shipping in its current state. This "cashing out" of earned value to ship a minimum viable product that is deemed "good enough" can provide the business (not just the Scrum team) with a significant agile advantage.