The Release Planning Workshop

Determining the release date and budget before development starts can be tricky particularly for new or young products where the product backlog contents are not known upfront. This blog post discusses the use of a measurable release goal and collaborative workshop to determine the launch date and the budget before the first sprint starts.

Bring the Right People Together

Employing a traditional planning approach and trying to capture all requirements in detail upfront in the product backlog is not only error-prone when dealing with innovative products. It is also undesirable in an agile context where the product’s detailed functionality is discovered during the development through early and frequent user feedback.

Does this mean that we cannot make an informed investment decision at an early point in time on an agile project? Luckily, the answer is no. A collaborative workshop involving the right people is a great way to carry out the initial release planning: The product owner, the ScrumMaster, the development team, and key stakeholders should attend the workshop. An initial product backlog must be available before the workshop starts.

Agree on the Release Goal

Choose the a release goal, the reason why it is worthwhile to work on the product for the next two to six months and create a new product version or major release. Sample release goals are acquire more or new customers, increase revenue, reduce cost, increase engagement, reduce technical debt. If you work with a goal-oriented product roadmap, then the plan should provide you with the goal. Make sure that the release goal is specific and measurable so that you will be able to determine if it met or not. Additionally, everyone present should understand and agree with the goal.

Identify the Window of Opportunity

Next determine the window of opportunity, the timeframe in which the new or updated product must be released to meet the release goal and create the desired benefits. If the date is missed, the opportunity may be gone, and releasing the product no longer makes sense. If the release goal cannot be met in the desired timeframe, try making the goal less ambitious or explore if adding more people to the release would be feasible and beneficial. This may require you to adjust your product backlog and remove or change some of its items.

Determine the Budget

With the release goal and date in place, determine the budget. To do so, ask which skills are needed and how many people may be required. Then consider additional items such as licensees for tools and third-party software. This provides you with an initial budget. If the budget is too high, consider acquiring more money or weakening the release goal.

Make a Go/No-go Decision

Having a release goal, date, and budget available should allow you to make or recommend a go/no-go decision. Making the decision in the workshop does not only create transparency and leverage the input of the attendees; it also avoids waiting and delays and helps reduce time-to-market.

Track the Development Progress

Once development is underway, capture the progress using a release burndown chart, as shown in the picture below. The chart tracks the remaining effort in the product backlog at the end of each sprint. This is the burndown line. By seeing a trend emerge across the sprint, you are able to forecast the likely development for the rest of the release.

Working with a release burndown chart validates the original plan, and it allows you as the product owner to steer the release and trade off time, budget and functionality. Note that quality is frozen in an agile context and should not be compromised: Quality compromises result in defective product increments, making it impossible to clearly see the progress and to release software early and frequently.