Release Planning for Scrum Masters
Although flexibility and adaptability are part and parcel of an agile framework, this does not mean that no planning is required when following the Scrum framework. In fact, there are a number of different levels of planning that need to be undertaken when taking this approach.
One of the fundamental concepts of Scrum is to have regular iterations, or sprints, and to produce a ‘potentially shippable increment’ by the end of each sprint. However, releases do not necessarily need to be tied in with the timing of the Scrum cycle. On the contrary, releases can and should be planned separately from the sprint itself, as the ideal time to release a feature or fix might not match the cyclic nature of the sprint.
Why do we need Release Planning?
When agile is first introduced into a company, some stakeholders may be wary and uncomfortable because of the shift away from defining all deliverables up front and in detail before development starts. With agile release planning, all the parties involved get together and decide what the priorities are and what the team should be focusing on for the upcoming period. At this point, requirements are only specified at a high level and will be refined later during the sprint planning process. As a result, there is no effort wasted on defining requirements that may end up being de-prioritized because items of greater value have been chosen for delivery.
In addition, the iterative nature of Scrum means that the release plan is constantly being refined and validated, and therefore the contents of the release will always reflect the most up to date information on what is most valuable to the company. Release planning allows the team to clarify what they are able to commit to within a release and ensures that there are no nasty surprises for the stakeholders when the delivery date is in sight.
Teams that have adopted Scrum are likely to have also reached an agreement with management and customers about how often a bundle of changes will be grouped together and released into production. This would normally mean having a given number of sprints and then delivering a release each time a set of sprints is completed. It makes sense for features to be assembled and delivered together in this way because a regular pattern will then be established. This is especially useful when there is integration with work being done by other teams, which will require tasks and activities to be scheduled outside of the Scrum team.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Occasionally situations will arise where changes need to be applied outside of the regular release cycle. This could happen for a number of reasons, such as a malfunction that needs to be addressed quickly and cannot wait till the next release, or a sudden change to legislation that requires an immediate software update. In these cases, the value of having a distinction between release planning and sprint planning becomes more evident, as the team will already be equipped to handle and accommodate the unforeseen requirement.