The delivery plan

A few days ago I made a new retrospective with “benexters” at their clients. This is an opportunity to have a fresh look with hindsight (and experience) to support them in their activities. Several subjects stand out. And in particular something that makes me tell them quickly: no delivery plan (release plan)? Well no, no delivery plan. It’s a pity and frequent. This is a highly effective tool for communicating, harmonizing points of view, bringing out contradictions or needs, facilitating decision-making, etc. In short, it is a central element of product or project support. And it is too often forgotten.

It’s simple, and very effective, and a few small details seem crucial to me.

Here are a few telling examples (but always imperfect, “it’s real life”) that I would like to comment a little. The rest should be self-explanatory. (The content is blurred for obvious reasons).

Example 1

Delivery Plan 1

A three-month plan. This could be 6 months or even 1 year or 2 years (but as the distance increases, the blocks would get bigger and bigger, as they become more and more approximate).

An indicator that tells us where we stand. You are here. What before, on the left, is done, finished, ideally in production. We observe a validated, confirmed pace (unless you say it’s finished only to discover that it isn’t, hence the interest in going into production). And, on the right, we project ourselves. Estimates, ideally based on what is on the left (we reproduce a cadence).

On the right what is estimated? a) the estimates are always wrong so b) the plan is constantly updated (a part on left which shows the real cadence, on right the projection: sometimes it’s consistent sometimes it’s anything to please someone).

In the cartridges, the content of each iteration. Here the title is blurred, but it’s something short and speaking for all the actors. The cartridges represent the capacity and they are in fact very important. It has nothing to do with a gantt.

Red triangles? Here events, in this context: Christmas, New Year’s Day and Chinese New Year’s Day, which impact the teams. This should impact the content of the iterations, not the case here, we have to face it. In any case it is important to show key moments on the delivery plan.

Example 2

Release Plan 2

Here the gray cartridges (time spent), the color cartridges (projection).

We also categorized user stories (user stories) or features (features) by colors. Imagine what suits you. Here it was the horse betting of a certain color, the sports betting of another, finally the customer relationship of another.

Still the markers above: deadline for legal certification, date of the European football cup, but also the yellow star indicates when you can take the product out, even if you don’t make the last cartridges.

Example 3

Release Plan 3

In this example I want to show the inclusion of an iteration on the legacy code, on another subject, suddenly, in the middle. This shifts the cartridges or the contents of the cartridges. The capacity doesn’t change. Hence the importance of the cartridges, and not a gantt type of mille-feuille approach.

Verticality for reading seems important to me.

Example 4

Release Plan 4

This example is fictitious. It allows me to show you how you can aggregate several delivery plans into one to see the dependencies.

Example 5

Release Plan 5

It’s a team that was working on five different versions of its product in parallel. But it could also have been five teams working in parallel to join the example above.

Did you note that this took place over two or three years?

Example 6

Release Plan 6

One last example: projection at 4 months, no past yet, damage; colour codes.

A logical sequence

Delivery plans are the last elements of a classic route. A classic route? Not all the options are indispensable, but for example: a clean canvas for the need, then an impact mapping(in french) for the strategy, then a user story mapping(in french) for the tactics of implementation, and perhaps an extreme quotation(in french) for the “estimates”.

Who does and when ?

The person in charge of the product, of the project, is responsible for it (he can delegate, I suppose, he manages).

The update is regular: at each iteration. It doesn’t mean big upheavals, just an update if needed.


We share it with all the actors. Delivery plans made in this way can stress decision-makers who understand very well (they are never foolish) that if they add something the rest shifts. But this is an honest view of the state of affairs. They perceive the variability of their demands if it exists. Everybody perceives the pace, because it appears to everyone. The delivery plan is therefore a highly political element in the good sense of the word, which concerns the citizen of the city, the actors or stakeholders of the product, of the project.

Complement following publication

I hear: “we synchronize with 17 teams (…) even if it’s useful after a week it becomes wrong”. Beware, my experience makes me think that beyond 5 or 6 teams the synchronization will be difficult, very difficult. Synchronization is keeping simultaneity. You can make a table for more teams, but then yes I agree it’s very ephemeral, you have to ask yourself if the game is worth the candle. And it is no longer a delivery plan that is well maintained constantly and therefore always up to date. You can aggregate a maximum of 5 or 6 delivery plans so that it remains a living element of decision and follow-up. So no “big projects” has more than 5 or 6 teams? Yes, of course, but you need to work on your organisational breakdown: groups of 5 or 6 teams maximum, which themselves aggregate in clusters of 5 or 6 groups maximum, etc. Large tables that aggregate everything are very nice but useless, because they are not understandable, too dense, not maintainable, etc. The delivery plan is a monitoring and decision-making tool. This is what we need.

plan delivery release planning