Release Management

Releases are points in time when a new or modified system is delivered and can be used by users.

Initial release plans are created at the beginning of projects which outline what new or modified functions will be available from a given point in time.

Deliveries in Scrum are products that are developed in Sprints. In Scrum, the remaining effort is estimated for the tasks to be developed each day. The remaining effort of the remaining Product Backlog after every Sprint results in a Release Burndown Chart.

Diagram 14 shows how much effort is left after individual Sprints for the implementation of Product 1. If the effort is specified in hours it means that 10 Sprints are required to process around 500 hours of effort.

Scrum Product Burndown Chart

Diagram 14: Product Burndown Chart

There are certainly projects in which the requirements or framework conditions change so slightly that actually result in a Burndown Chart similar to Diagram 14. In the development of complex (software-) systems, requirements change, for example, in the following way:

  • the customer prioritizes requirements differently
  • during the run time more effort is invested in individual, particularly important functions
  • the familiarization effort in a new technology is higher than first thought
  • there are requirements which are no longer needed

Therefore, the following Burndown Chart is more realistic.

Scrum Product Burndown Chart (Realistic)

Diagram 15: Product Burndown Chart (Realistic)

Diagram 15 shows that from the outset, more training efforts which have not been taken into account have occurred, or similar, because the effort is higher after the first Sprint or equal to the effort as planned at the beginning.

In addition to the remaining effort, the next diagram describes the so-called Velocity, which indicates the processed effort of a Sprint.

Scrum Product Burndown Chart with Velocity

Diagram 16: Product Burndown Chart with Velocity

This diagram gives information about the remaining effort after each Sprint at the end of the implementation of a product. During the development, trends are of course deducible which result from the previous curves. When the racing line is not reached now, the reason cannot be read from the diagram shown. That is why it is necessary to gather further information.

It must first be clearly noted as to what extent the effort has come from changes to the existing requirements. It should also be noted as to what extent new requirements have been incorporated or existing requirements have been omitted. Detailed statements can then be obtained from these data.

The following diagram shows an extended Product Burndown Chart (PBC). The efforts are plotted in hours on the y-axis. The individual Sprints can be seen on the x-axis. This Burndown Chart illustrates when the product would have been delivered if there had been no changes.

Scrum Extended Product Burndown Chart

Diagram 17: Extended Product Burndown Chart

The Burndown line shows the initially planned tasks which have been implemented. Remaining displays the remainder of the total effort, Changes is the sum of the changes during the project lifecycle. Each line in this graph is associated with a trend. The trend of the line Remaining states when the development is completed and if further changes have been taken into account as before. Further important indicators can be calculated from the data collected. It is now important for the project manager to find out how much can be implemented from the initially planned effort in the current situation.

The following indicators are required for further planning statements:

  • Total Burndown: Provides information on how much effort can be burned down from the initially planned effort per Sprint.
  • Added Work: Provides information on how many changes have emerged on average per Sprint.
  • Team Burndown: Provides information on how much effort the Team has actually burned down, including the changes.

For our example, the following indicators emerge for the first 10 Sprints:

Scrum sprint indicators

Table 3: sprint indicators

The given example means that the Team can execute 111.5 hours of effort per Sprint. Of this effort, 44.5 hours are averaged on changes and 67 hours on initially planned effort.

Evaluation and Forecast

Releases must also be planned in agile projects. Rough estimates of the planned functions per Sprint are required to give a total effort.

If changes and their reasons for change cannot be understood in the initial plan, then no conclusions can be drawn with regard to the causes of a failure.

This version focuses on changes in requirements and additional requirements. When these are logged, it is easier for the project manager to show the status of the project to the customer. With this method it is possible to give information based on trends for implementation times at any time, and similarly the project manager knows enough about what has changed compared to the initial plan.