Release plans are not menus.

Release plans are not menus.

Developing an Agile release plan can be relatively easy. In general there are only a few moving parts. The inputs into the release planning exercise are:

  • Prioritized and Sized Backlog – The backlog represents the work to be done including bugs, features, technical items and knowledge acquisition annotated. Each item on the backlog needs to be sized using a unit such as story points, t-shirt size or function points. The backlog is prioritized by the product owner based on value, dependencies and business requirements.
  • Team Velocity or Productivity – Velocity and productivity are measures that represent how much work is normally completed in a sprint by the team or teams involved in a project.
  • Release Strategy – Two macro release strategies are often considered. The first is a time-boxed approach (fixed amount of time) or a scope-boxed (fixed amount of scope). The strategy will be used to determine what will be included in the release.

Using a simple approach for release planning, the process begins with the prioritized and sized backlog. The product owner and team walk through the backlog counting off sprints using the velocity or productivity to determine what can be done. The whole team is usually involved in the creating the release plan; however the responsibility for the plan lies with the product owner. Based on the strategy selected the release will occur when a fixed number of sprints are completed (time-boxed) or when a fixed amount of features are completed (scope-boxed). At the end of every sprint the process will need to be revisited based on the results of the sprint, work items may have been completed, not completed or new items discovered. This is a simple approach to release planning; however even more complex, scaled-up methods follow the same basic steps. In many projects I have used these basic techniques with sticky notes and brown butcher paper as tools to record the process.

 

Advertisements