Agile Release Planning (Part 1)

Release planning process in an agile team is to facilitate a dialogue between the team and the stakeholders and to answer the question of which functionality the project is likely to deliver by when. A release plan is not a once off document which is created at the start of the project. Rather release planning takes place throughout the project as the project team listens and responds to user feedback. In an agile team the release planning is a more collaborative effort and keeps the process more transparent.

During the release planning process team discusses about which of the three project lever i.e. time, cost or functionality can not be compromised to launch the product successfully. Is the a set window of opportunity for the product in market which makes the launch date mandatory? Or is it the budget which is fixed? Or there is a minimal set of functionality which has to be delivered? From experience on many agile projects it has been learnt that fixing all of these levers is not possible. At least one of these levers has to be flexible. On most of the market focused projects the objective is to make use of a particular market opportunity and often the customer requirements are uncertain. Therefore in these cases projects respond well when time is fixed but functionality is flexible. There are also certain advantages of releasing the product early. It gives an opportunity to product teams to test the product in the market and learn from feedback. The feedback can be used to improve the product during the later phases.

However in certain projects where the functionality is determined (e.g. legacy systems) and has to be fixed the other two levers must be flexible. It is not possible to fix the budget with these type of projects when functionality is fixed because the complexity of the system re-implementation may be unknown. Similarly by fixing the time while the functionality is fixed but complexity is unknown will also be counter-intuitive.

A product’s vision determines the window of opportunity  for the product to achieve the desired benefits and therefore should be used to determine the product launch time. By setting the launch date the time is considered as a scarce resource and other variables are adapted to this. However the teams should keep an eye on the product quality as a launch date is not an excuse to compromise on the quality of the product.

In my experience choosing a launch date based on the work in the product backlog is difficult. It forces the team to freeze the requirements and often results in a poor estimate. In fact an estimated launch date based on requirements may be off by as much as 60 – 160% (Cohn 2005). Identifying a launch date and focusing everyone on the window of opportunity will avoid these issues.