Essential Release Planning

Release planning is, in essence, very simple. I am speaking here of planning what changes are to be made for each software release. The planning of a release into an operational environment is a different type of release planning entirely!

Here is a simple way to think about releases and release planning.

Think of a release as a bucket into which change requests can be placed. A release plan is essentially a line of release buckets. Changes can be add to, removed from, or moved between release buckets.

Each bucket is assigned a ‘release date’. This is the date on which that release bucket ceases to exists and the system that results form all its changes is given to the client.

In a very simple development schedule, developers visit the next bucket in line, take out a change, make that change and mark the change as done.

Here are some rules about how the release buckets are used for release planning.

  • Each bucket has a certain capacity measured in man days effort. Each change requires a certain number of man days effort to complete. The release manager can add or remove changes so long as the total effort associated with the changes does not exceed the capacity of the release bucket.
  • When planning releases it is best to not exceed 80% of the capacity of the release bucket in the early part of the release’s lifecycle. This allows some contingency for late change or some changes already in the bucket overrunning slightly.
  • Changes that have not yet been taken by developers can be freely moved between release buckets.
  • Changes that have been started by developers can only be moved in co-operation with the developer and software configuration manager. (This is a practical matter of moving the code changes in the version control system.)
  • As a release approaches its assigned release date, make it harder to add and remove changes.

I recommend adopting a traffic light approach to locking down a release; green (changes can be added and removed freely, providing 80% of the bucket’s capacity is not exceeded), amber (changes can be added or removed only with senior project approval, 80% capacity can be exceeded if approved), red (no further changes other than for integrating emergency patches from live).

The precise meaning of terms such as ‘senior project approval’ will be different for different projects. The point is, it should be more difficult to make changes to the content of the release bucket once it is in the amber condition.

As for when you set a release to amber or red, that depends on your own schedule, the size of your release, and the resources available.

Advertisement
  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.