Theory "Release Planning"

A Release Planning Meeting can take place at the beginning of an agile project. This meeting is not an official Scrum Event, which means that it does not have to be held. You may be wondering why we are presenting this chapter at the end, even though it would normally be at the beginning of a project. We have thought about it for a long time and have come to the conclusion that it is better at the end of the online course for the following reasons:

• It is not an official Scrum Event - whether you want to do it or not is up to you.

• The prior knowledge you have gained during the course makes this chapter easier to understand.

Long-term planning and milestones¶

These two buzzwords are probably more associated with traditional project management and not with agile project management in general or Scrum in particular. Nevertheless, they play an important role in release planning. Release planning is also called long-term planning or roadmapping. If it is part of the project, it is carried out at the beginning of the first Sprint. During the meeting, "milestones" of the upcoming project are discussed and defined. Functions to be released are specified, and the timing of the release is planned.

Release planning is usually done because customers want to get a rough idea of:

• when they can expect a release,
• what features they can expect and
• what costs they can expect.

Release planning also creates a certain level of trust between the Scrum Team, the stakeholders and the customer. With the release plan, the customer has a document that allows them to visualise the course of the project. In addition, the release can be presented in a release burn-down chart.

Types of release¶

As already explained in the chapter Sprint, the finished Increment must be potentially deliverable. In the case of products that are not software, however, it may make sense to carry out a bundled release after a few Sprints rather than after each Sprint. Depending on the wishes of the customer or the Product Owner, a release can be function-driven or time-driven - or based on both.

Function-driven release¶

The function-driven release is useful if the customer wants a certain scope and a release only takes place once this scope has been achieved. The release date is calculated by dividing the desired scope or the total effort in Story Points by the velocity.

Time-driven release¶

A time-driven release should be used if the Increment or product must be ready by a certain deadline, e.g. because an event is taking place at which the product is being presented. The calculation for this is similar to that of the feature-driven release, except that it is reversed: at this point, the Story Points have to be calculated by multiplying the velocity by the number of Sprints until the release date. These Story Points are used to find out which PBIs will be implemented. If it turns out that the time frame is not sufficient, the scope of delivery and performance may have to be reduced.

Function- and time-driven release¶

In the case of the function- and time-driven release, both the scope and the release date are fixed. This type of release is challenging because both the number of Sprints and the number of Story Points are fixed and therefore the velocity must also be stable. The release date is calculated by dividing the desired scope or the total effort in Story Points by the velocity.

Continuous revision of the release plan¶

At the beginning of the agile project, planning is in many cases only possible to a limited extent:

• The Product Backlog consists of many entries that are subjective and usually have to be largely adapted.
• During the course of the project, new entries are added, older entries may turn out to be obsolete and are deleted.
• The velocity of the Developers in implementing the entries is not known at the beginning of the project and may have to be estimated.

The sum of all estimated entries in the Product Backlog allows precise release planning only as soon as the velocity of the Developers is known. If it is a newly formed team or the first time a Scrum project is carried out in the company, the velocity can only be determined in the course of the project. Therefore, it is important that release planning is ongoing. In addition to the Release Planning Meeting at the beginning of the project, we recommend holding such a meeting at the beginning of each Sprint to update the release plan. Through continuous adjustment, the plan becomes increasingly accurate.

Congratulations, you have now completed all 11 chapters that are relevant for passing the Certified Junior Agile Project Manager (IAPM) certification exam. You have now mastered everything that is important to carry out a project within the Scrum framework. Only one thing remains: your certificate from the International Association of Project Managers (IAPM).