HOMESCRUMPREPARATIONROLESPROCESSARTEFACTSFAQLINKS

Release Planning

A Release Plan provides a view of what we think the team(s) can accomplish by a given date. Release Planning is something that occurs all the way through a project, not just at the beginning. The plan will start with a large margin of error (unless your teams are already established with known velocities) but become more and more refined as the plan responds to empirical data flowing in as the project progresses.

The key to Release Planning is to have the Product Backlog in a good shape. Specifically it will need:

  • To be reasonably complete with both functional and non functional stories
  • Prioritised by business value
  • High level estimates against each story
  • An estimate of team(s) velocity - more accurate when based on actual team velocity after a few Sprints

If the project is Time Driven and has a specific deadline then the team(s) velocity will indicate the total effort that can be expended by the deadline. Starting at the highest priority backlog item, work down until the cumulative effort reaches the total available; this will show the set of features that can be delivered by the deadline with the current team capacity.

If the project is Feature Driven, calculate the cumulative effort required to build the desired feature set and divide by the team(s) velocity to estimate the amount of time required for delivery with the current team capacity.

As the team(s) progress through Sprints, their actual velocity can be applied to the Backlog to assess how the Release Plan stands up to reality. The Product Burndown Chart provides this view of progress and is an important input into the Release Planning exercise.

It is just a fact of life that the desired functionality will require more than the available time, effort and budget! Based on project progress we make changes to the variables available: time, team capacity and scope. The most effective means of control is variation of scope. Scope control at its simplest is the deferral of backlog stories to a later release thus reducing the scope for the current release. However, it is also important that Backlog stories be "Negotiable" so that their desired outcome can be achieved by pragmatically adjusting the sophistication of the implementation.