Theory "Release Planning"

A Release Planning Meeting can take place at the beginning of an agile project. This meeting is not an official Scrum Meeting, which means that it does not have to be held. You may be wondering why we are publishing this chapter at the end, when it is 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 defined and it is planned when this release should happen.

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

• when they can expect a release,
• what features and
• 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 with which he can visualise the course of the project. In addition, the release can be presented in a release burn-down chart, which you already know from the previous chapter.

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 interesting if the customer wants a certain scope and a release only takes place once this scope has been accomplished. The release date is calculated by dividing the desired scope or the total effort in Story Points by the Velocity.

Time-driven release¶

Time-driven release should be used if the Increment / the 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 has to be changed: At this point, the Story Points have to be calculated, i.e. the Velocity is multiplied 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 time frames are not sufficient, the delivery and performance item can be shortened.

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 tricky 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 Developer to implement 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 to carry out such a meeting at the beginning of each Sprint to update the release plan. Through continuous adjustment, the plan becomes more and more accurate.