Release planning

“When will it be done?” is a constant refrain from management. Traditional project management has never been able to answer this question well. Research shows that only about 15% of Waterfall projects come-in on time. Scrum does a much better job, but {{p|release planning is always a challenge. Here are some tips on how to do it right.

The Process

Estimate the number of story points in the project at hand, build your product backlog, and then start sprinting. After three sprints, calculate yesterday’s weather—add-up the story points you completed and calculate the average. This is your velocity. Project a release date based on the amount of story points in the project and yesterday’s weather.

There are three types of Release Plans:

1. Deadline Driven;
2. Value Driven; and
3. Regular.

Often, circumstances dictate which type of plan the you will use.

Deadline Driven Release

A deadline driven Release Plan has a fixed date that is set for a particular business reason. If you can’t meet the deadline, you need to either increase velocity, reduce scope, or add resources.

stable teams should increase velocity roughly 10% each sprint. If done right this acceleration should continue until you achieve a 400% improvement in productivity. However, this requires consistent discipline and it is always wise to estimate this increase conservatively. This should help pull the projected date closer to the deadline. If the date is still out of reach, the product owner needs to reduce scope by eliminating the lowest priority items in the backlog. If this reduces functionality to the point where the product owner feels there isn’t enough value, the only solution is to add resources. In scrum, this means offloading part of the work to another squad or even adding an entire squad. Adding people to a late project will just make it later.

Value Driven

In a value or feature driven release the scope is fixed by the need to achieve a certain level of functionality. The team writes the user stories they need to achieve the functionality desired, estimates them, figures in their established velocity, and projects a date when they will be finished.

Regular Release

In a regular release plan, there is no level of functionality that must be met. The team sets the schedule by picking a particular cadence for the release (such as every sprint, or using a season beat) and whatever features are ready when that release date arrives are simply shipped. Think of it like people at a bus stop. A rider may have a particular bus she is hoping to catch, but if she misses it, she simply waits for the next one and hops on.

Regardless of the type of Release Plan, the product owner needs to translate the product backlog into a lightweight document that communicates to both the customer and management when the product can be released.

A regular release cycle like the season beat is highly recommended. With this type of schedule, you can work at a sustainable pace, creating daily clean code, reducing waste and developing the most valuable features first.

More

• broccoli planning
• season beat
• product portfolio
• release burndown chart
• release strategies
• story map
• golden triangle

Processable

• Fuse with release strategies and golden triangle.

Source

Source: E-mail from Jeff Sutherland infor@scruminc, 2013-05-10