Release Planning and Fixed Price Contracts

How to do Release Planning and Fixed Price Contracts
Sometimes we need to plan ahead more than one sprint at a time. Typically in conjunction with a fixed price contract where we have to plan ahead, or else risk signing something that we can't deliver on time.

Release planning is an attempt to answer the question "when, at latest, will we be able to deliver version 1.0 of this new system".

Define Your Acceptance Thresholds
In additionto the usual product backlog, the product owner defines a list of acceptance thresholds which is a simple classification of what the importance levels in the product backlog actually means in terms of the contract.

Here's an example of acceptance threshold rules:
 * All items with importance >= 100 must be included in version 1.0, or else we'll risk fines.
 * All items with importance 50-99 should be included in version 1.0, but we might be able to get away with doing them in a quick follow-up release.
 * Items with importance 25-49 are required, but can be done in a follow-up release 1.1
 * Items with importance < 25 are speculative and might never be needed at all.

These acceptance thresholds can be implemented in the product backlog color-coded based on the above rules.

Time Estimate the Most Important Items
In order to do release planning the product owner needs estimates, at least for all stories that are included in the contract. Just like when sprint planning, this is cooperative effort between the product owner and the team - the team estimates, the product owner describes the items and answers questions.

A time estimate is valuable if it turns out to be close to correct, less valuable if it turns out to be off by, say, a factor 30%, and completely worthless if it doesn't have any connection to reality.

A general guideline is to:
 * Let the team do the estimates.
 * Don't make them spend too much time.
 * Make sure they understand that the time estimates are crude estimates, not commitments.

Usually the product owner gathers the whole team and tells them that the goal of this meeting is to time-estimate the top 20 (or whatever) stories in the product backlog. He goes through each story once, and then lets the team get to work. The product owner stays in the room to answer questions and clarify the scope for each item as necessary. Just like when doint sprint planning, the "how to demo" field is a very useful way to lesson the risk of misunderstanding.

This meeting must be strictly time-boxed, otherwise teams tend to spend too much time estimating too few stories. If the product owner wants more time spent on this he simply schedules another meeting later. The team must make sure that the impact of these meetings on their current sprints is clearly visible to the product owner, so that he understands that their time-estimating work doesn't come for free.

Release Plan Input
When time estimates for the most important stories are done, estimate the average velocity per sprint. The next step is to chop the product backlog into sprints.

Each sprint includes as many stories as possible without exceeding the estimated velocity. The result is a product backlog that shows how many sprint is needed where all "must haves" and "should haves" are included.

As an example, lets say the result is 3 sprints with the velocity of 45. 3 sprints = 9 calendar weeks = 2 calendar months. In addition It is wise to add a significant buffer to protect agains bad time estimates, unexpected probelms, unexpected features, etc. So in this case we might agree to set the delivery date to 3 months in the future, giving us 1 month "reserve".

The nice thing is that we can demonstrate something usable to the customer every 3 weeks and invite him to change the requirements as we go along (depending of course on how the contract looks).

Adapting the Release Plan
If the actual velocity in a sprint is very different from the estimated velocity, revise the estimated velocity for future sprints and update the release plan. If this puts us into trouble, the product owner may start negotiating with the customer or start checking how he can reduce scope without breaking the contract. Or perhaps he and the team comes up with some way to increase velocity or increase focus factor by removing some serious impediment that was identified during the sprint.

The product owner might call the customer and say "hi, we’re running a bit behind schedule but I believe we can make the deadline if we just remove the "embedded Pacman" feature that takes a lot of time to build. We can add it in the follow-up release 3 weeks after the first release if you like".

Not good news to the customer perhaps, but at least we're being honest and giving the customer an early choice - should we deliver the most important stuff on time or deliver everything late. Usually not a hard choice :o)

Recommended reading
- Mike Cohn, "Agile Estimating and Planning"