Gone Are Release Planning and the Release Turndown

Any Product Manager that has successfully delivered a product to a customer knows how incredibly important Release Planning is. Despite its importance, the 2011 Scrum Guide, published in July by Ken Schwaber and Jeff Sutherland, removes any discussion about Release Planning and the related Release Burndown chart. Professional Scrum Trainers Ralph Jocham and Henk Jan Huizer explain these changes:  

Why remove items from the Scrum Guide?

The Scrum Guide, the body of knowledge for Scrum, has grown over the years to address the expanding array of questions people have about successfully using Scrum. In the recent update of the Scrum Guide, Ken and Jeff decided to remove most of the tips and strategies and only keep the basic rules by which Scrum has to be played. This may seem to be a strange choice given that there are still thousands of potential questions about how to use Scrum.

But there is a good reason for the removal of implementation strategies and tips. Simon Sinek argues that one should always start with the “Why,” and only then move on to the “How” to at last finish with the “What.” The previous version of the Scrum Guide described a lot about What has to be done. However, describing theWhat closes the door on alternative and possibly better approaches. In contrast, describing the Why prompts people to think for themselves about how to apply the concepts in their own unique context. Removing much of the What from the Scrum Guide also prevents copy/paste behaviors, blindly following the rules, without understanding them, just because it happened to be successful in another situation; thereby creating a cargo-cult.

This article focuses on the removal of Release Planning and Release Burndown from the Scrum Guide.

Why do we have Release Planning?

In the software industry products are commonly delivered to customers in official releases. These can be single big releases at the end of a project, or more incremental releases on a quarterly or even a yearly cycle in the case of product development. Although releases are common, they conform to the weaknesses of software development, and don’t leverage the incremental and iterative process of an Agile framework like Scrum. When Scrum is used well, potential value is created with every Sprint. But if the increment isn’t released with every Sprint, we are not delivering that value to our customers. We actively seek feedback from users, so why don’t we make it easier by releasing the increment from Sprint to Sprint?

The practice of software releases exists because it is not always practical to constantly deliver what is being built. Scrum requires that a product Increment at the end of a Sprint be potentially usable. This does not mean that it is necessarily useful. So, there is often a need to batch usable Increments from subsequent Sprints into something that is potentially useful for a customer.

Unfortunately, some organizations use releases to compensate for bad development practices. A usableIncrement is one with no “undone” work associated with it at the end of a Sprint. If teams are unable to create truly usable Increments, the remaining work (testing, documentation, user acceptance, etc.) are done as part of the release process - sometimes referred to as the stabilization phase. In this case, the release plan codifies the acceptance of the poor development practices, and makes it incredibly difficult for a Product Owner to effectively plan when a release will happen.

However, even if a release is constructed of usable Increments, and is potentially useful for a customer, a lot of things have to take place for a customer to actually get value from it. This process of integrating a release in order to extract value is called absorption.

To readily absorb a release, customers may have to go through extensive installations, trials, pilots, rollouts, training, certification, and a host of other processes before the release can create value. Being aware of, and actually planning for, these activities that need to be done to help customers extract value is why release planning is done. This is the reason why the previous Scrum Guide included release planning.

Why do we have Release Burndowns?

Scrum is an empirical framework built upon the three pillars of transparency, inspection and adaption. In order to adapt we have to inspect, and in order to inspect we need transparency. We use a burndown because it provides transparency into how we are doing over a given time frame. It allows quick answers to questions like, “Are we on track, are we ahead, or are way behind?”

Scrum is used in complex environments, like product development, where circumstances change on a daily basis. Requirements change, technical challenges are encountered often, and the organizational environment changes on top of that. Scrum accepts that changes are part of the process of complex software development and embraces them. In order to deal with changes, we need precise up-to-date information.

The release burndown provides exactly this piece of information towards a release goal. The inspection opportunity the release burndown allows provides the precious ability to adapt immediately when changes are realized. It gives the Scrum Team the chance to ask the hard questions early, instead of waiting until the week before the planned release date.

Why has Release Planning been removed from the Scrum Guide?

The answer is short and simple: it is possible to successfully use Scrum without using release planning. Not needing release planning may actually be a positive indicator of a product’s health. Scrum is intended to deliver value to customers continuously through short iterations. Using releases may actually delay the delivery of value, customer feedback, and return on investment (ROI). With mature development practices and excellent rollout strategies, the delivery of value can take place every Sprint.

Is Release Planning no longer allowed in Scrum?

Release planning is still incredibly valuable in many cases. It is often difficult to deliver a complex business solution in the short time frame of a single Sprint. Sometimes extensive test periods are needed to satisfy rigorous quality requirements. Large enterprises sometimes require infrastructure changes. And sometimes customers don’t like frequent releases because they actually create more pain than value. In these scenarios release planning is a valuable activity, a way to come up with a plan, a roadmap of what can be expected after a couple of sprints, and what will be part of the release and what won’t.

Why has the Release Burndown been removed from the Scrum Guide?

As Scrum no longer requires release planning, it makes no sense to require a release burndown. Scrum strives to make the process of software development and delivery transparent. A burndown can be incredibly useful in supporting this. But, there may be other ways to achieve this same objective. By removing the guidelines on What to do, Scrum can benefit from future innovations.

The 2011 Scrum Guide returns to its roots. Less can be more! But don't be fooled by 16 pages of rules; the game of Scrum is simple to understand, but difficult to master.