Make a planning release in agile

Some agilists don’t always like this concept but sometimes the context imposes to have to carry out planning release on the projects. We will see how to prepare releases in agile.

Prerequisites for the release planning

1/ Objectives and dates

Indeed, some companies don’t want to go beyond deadline concepts. So, it’s necessary to clarify concretely what the objectives of the release will be.

In case of delay compared to the planned schedule, these are the objectives that will allow us to make any choices on the user-stories to be removed or not; but we try that the delivery delay will be accepted by management.

I strongly advise to display these release objectives on a board dedicated to the release so that all elements concerning the release are visible to everyone.

The Release Board to do our planning release that we will see below can be done for various purposes listed below:

• look for a landing date for the project
• define the resource requirements to go to the required release date
• validate or invalidate that the desirable delivery date is realistic
• define the content that could be delivered at the required release date

2/ Determine the elements of the release backlog

When the objectives are defined as well as the possible date of delivery, it is necessary to define all the elements that we would like to see in this release.

However, if all the elements of the release are not yet estimated (which will normally be the case), it’s possible that the list comes to be modified when you have estimated everything.

3/ Estimate all elements of the release

I advise you to consider doing an Extreme Quotation that will estimate more user-stories in a minimum of time. The goal of the workshop will be to have an estimate to imagine the contents of the sprints of the release.

If you trigger large Product Backlog Refinement, you will do too much effort on each of the user-stories whereas they may never be developed in the future.

Extreme Quotation will not prevent you to do Product Backlog Refinement in the future when the user-story will be more mature to be developed.

Article: Let’s estimate with Extreme Quotation

4/ Have a fixed duration of Sprint

It’s essential to have fixed sprints and to determine the sprints duration during the realization of your release. This stability is essential to be able to do your planning release.

5/ Can calculate the capacity of the next sprints

To make our release, it will be necessary to be able to calculate the capacity of the next sprints.

However at the beginning of the project, you have no idea of ​​the capacity to do; I advise you to ask the developers to propose a first sprint they would be able to achieve to get an idea of ​​the capacity to do the first sprint. We will deduce the capacity to do each sprint of the release.

Les user-stories mises par les développeurs étaient uniquement pour se faire une idée de la capacité de faire, mais le Product Owner pourra revoir leur emplacement à la suite de cet exercice.

The user-stories put by the developers were only to get an idea of ​​the capacity to do, but the Product Owner may review their location following this step.

Determine a schedule release

Here is for example the representation of our planning release that it’s very simple to achieve:

Release tracking (planning release)

In general, we also put in place a release Burndown Chart that will show how our release progress. If we do a daily follow-up, we will be able to quickly know if the project is delayed or not compared to the initial estimate.

If the scope changes over time, which is supposed to be the case, don’t forget to update your Burndown Chart Release. It’s essential not to block at the initial scope.

Release is delayed (planning release)

If the team has not been able to issue as many requests as expected (requests in Done), we will have to make a choice on the strategy to take:

1 / Either review the landing date of our release and go without waiting to notify the stackholders or managers impacted.

2 / Adapt the content of the backlog of our release to always deliver on the expected date with the risk to degrade the content of the release.

However in agile, we would prefer the second method because a scope constantly lives and is never constant. Some will make an exception if there is a MVP (Minimum Viable Product) set and it is not reached.

Here’s how to mark the new landing on a Burndown Chart:

Conclusion : planning release

Now, you have all the elements in your hands to be able to make a planning release with your teams. Don’t hesitate if you have any questions about this planning release.