Overview
There is a common misconception that there is no planning in Scrum. While there is nothing in the latest Scrum Guide (http://www.scrum.org/scrumguides/) specifying Release Planning, the omission is intentional. The guide is not definitive; it is the core outline of Scrum. It is more the poles of the tent than the canvas.
Release Planning is very critical for organisations in transition to a continuous delivery model (http://en.wikipedia.org/wiki/Continuous_Delivery). If you can release in to production smoothly every Sprint, the amount of work completed in a Sprint is a useful amount, there are no quality issues in production, and your business and engineering teams are working together to create well groomed independent Product Backlog Items – then you will probably not use release planning. You will release at the end of the Sprint.
If there is some issue that prevents this flow of change in to production, you will need to structure your release plan to fit with the business. This planning is necessary when you are trying to determine how much many long it will take to complete a set of features (Release by Feature), or how many features can be completed in a set time (Release by Time).
There are 2 main ways to plan a release
1. Release by Feature
2. Release by Time
Both are constrained by the engineering velocity - the number of Story Points that the engineering teams can complete within a Sprint. For this there will need to be a history of at least three sprints to give the metric. If this is the first time a specific team (if you change the people – the velocity will change) is working together you will need to estimate the team velocity. You should also be mindful of the lowest (worst case) and highest (best case) velocity. This will provide a Release forecast range.
Release by Feature
The focus in this pattern is to decide what group of PBIs has the optimal business value in a release. Once this has been determined, the velocities of the team(s) that will be working on the release are used to forecast the range of dates that the features will be complete.
Consider the Product Backlog below. The PBIs are ordered by Business Value, and the Team has worked together to groom the backlog with estimated sizes in Story points.
| PBI Title | Size (Story Points) |
| A | 5 |
| B | 3 |
| C | 2 |
| D | 8 |
| E | 3 |
| F | 5 |
| G | 3 |
| H | 2 |
| I | 5 |
| J | 8 |
| K | 13 |
| L | 8 |
| M | 13 |
| N | 13 |
The team has been working together for a while and has the following velocity statistics:
| Lowest Velocity | 13 |
| Average Velocity | 16 |
| Highest Velocity | 20 |
(If) All the PBIs up to N need to be completed to make the release commercially viable. There is a total of 91 story points in the Backlog.
| Forecast | Estimate/Velocity | Estimated Sprints to Complete |
| Latest Release Forecast | 91 / 13 | 7 |
| Average Velocity Release Forecast | 91 / 16 | 6 (5.7) |
| Highest Velocity Release Forecast | 91 / 20 | 5 (4.5) |
You can then have a predictive graph like:
The release will ship in 5 – 7 Sprints from the start of work, with the probability that it will ship after Sprint 6 (using the average velocity). There may need to be a further “Release Sprint” as the increment is promoted through the route to live in to production. You have to round up, as you need to use complete Sprints. It is not recommended to change a Sprint duration to accommodate a release – instead use the time to include another PBI. The team are working to 2 week sprints, so that is 12 weeks from the start of development.
Release by Time
The focus of this release pattern is to ship product increments at a regular cadence, or a specific deadline (regulatory work, peak trading period). This does not have to be fixed, as the ideal is to release to market as soon as possible. There are situations where the organisational mechanics require complex scheduling processes requiring a lot of different groups to be engaged to complete the delivery to production. There should be an action for the organisation to refine the delivery of software in to production that will reduce the size and complexity and cost of releasing code.
Consider the same backlog, using the following cadence: The organisational cadence is to release every 8 weeks, and requires a 2 week process to get code in to production. The team will then start to release after every 3 sprints, and every 4th sprint will have tasks to support the delivery in to production (the Release Sprint).
|
| Sprint Velocity (Story Points) | Release Velocity (Story Points) |
| Lowest Velocity | 13 | 39 |
| Average Velocity | 16 | 48 |
| Highest Velocity | 20 | 60 |
| PBI Title | Size (Story Points) | Total | Release Forecast |
| A | 5 | 5 | |
| B | 3 | 8 | |
| C | 2 | 10 | |
| D | 8 | 18 | |
| E | 3 | 21 | |
| F | 5 | 26 | |
| G | 3 | 29 | |
| H | 2 | 31 | |
| I | 5 | 36 | Low |
| J | 8 | 44 | Average |
| K | 13 | 57 | High |
| L | 8 | 65 | |
| M | 13 | 78 | |
| N | 13 | 91 | |
So using the velocity metrics, the initial plan is that Items up to PBI I should definitely be delivered, probably PBI J, and possibly PBI K.
This is the initial plan, and will be adapted at the end of each Sprint based upon the learning, feedback and velocity. It is also highly likely that the PBIs that are to be completed will change as a response to business needs.
One of the features of a Product Backlog is that the precision reduces the further down the backlog you go. Given that the team will continuously keep grooming the backlog, the Product Backlog Items after PBI I should get decomposed in to smaller, better defined items. This will get a better granularity and understanding of what will be shipped.
In the Product Backlog grooming sessions, the Development Team, the Product Owner and the Scrum Master would collaborate to ensure that planned PBIs forecast for the release are delivering the maximum business value possible. This is where the Release Plan is adjusted.
Summary
The choice between the two release planning strategies should be determined by what provides maximum value to the business while delighting the customers. This will often be influenced by the organisational release mechanics. By working within Sprints a predicted cadence will provide less friction for the Scrum team. If there is a decision to change Release planning strategies, this can be done at Sprint boundaries, to minimise disruption.
Once a release planning strategy has been selected, it provides the Product Owner and the rest of the business a forecast of the Product Backlog Items that will be delivered in the release. The forecast will become more precise the closer it is to the release date, as the uncertainty is removed by completing work and continuous grooming of the Product Backlog.
.