Faire une planning release en agile

Pas toujours aimé par l’ensemble des agilistes, parfois le contexte impose de devoir réaliser des planning release sur les projets. Nous allons voir comment préparer des releases en agile.

Les pré-requis pour le planning release

Pour faire une planning release, il faut commencer par connaitre l’ensemble des pré-requis pour le faire.

1/ Objectifs et dates

On a beau être agile, certaines entreprises ne veulent pas sortir des concepts de deadline. Il faut donc clarifier concrètement ce que seront les objectifs de la release.

En cas de retard par rapport au planning prévu, ce sont ces objectifs qui nous permettront de faire d’éventuels choix sur les user-stories à retirer ou non ; cela n’empêche pas de tenter de faire accepter un retard de livraison à la direction.

Je conseille fortement d’afficher ces objectifs de release sur un board dédié à la release afin que l’ensemble des éléments concernant la release soit visible par tout le monde.

Le Release Board pour faire notre planning release que nous verrons ci-dessous peut-être réalisé pour différents buts listés ci-dessous :

• chercher une date d’atterrissage du projet
• définir les besoins en ressources pour aller sur la date de release exigée
• valider ou invalider que la date de livraison souhaitable est réaliste
• définir le contenu qui pourrait être livré à la date de release exigée

2/ Déterminer les éléments du backlog de la release

Quand les objectifs sont définis ainsi que l’éventuelle date de livraison, il faut définir tous les éléments qu’on aimerait voir faire parti de cette release.

Cependant si tous les éléments de la release ne sont pas encore estimés (ce qui sera normalement le cas), il est possible que la liste vienne à être modifiée au moment où vous aurez tout estimé.

3/ Estimer l’ensemble des éléments de la release

Je vous conseille d’envisager de faire un Extreme Quotation qui permettra d’estimer plus de user-stories en un minimum de temps. Le but de l’exercice sera d’avoir une estimation pour imaginer le contenus des sprints de la release.

Si vous déclenchez de grandes Product Backlog Refinement, vous allez peut-être mettre trop d’effort sur chacune des user-stories alors qu’elles ne seront peut-être jamais développées à l’avenir.

L’Extrême Quotation ne vous empêchera pas de faire des Product Backlog Refinement à l’avenir lorsque la user-story se préparera à arriver dans un sprint prochain.

Article : Estimons avec de l’Extreme Quotation

4/ Avoir une durée fixe des Sprint

Il est essentiel d’avoir des sprint fixes et de déterminer le temps que feront les sprint lors de la réalisation de votre release. Cette stabilité est essentielle pour être capable de faire votre planning release.

5/ Pouvoir calculer la capacité des prochains sprints

Pour faire notre release, il faudra être capable de calculer la capacité des prochains sprints.

N’hésitez pas à vous référer à l’article qui explique de façon très détaillée comment calculer la capacité des prochains sprint : voir l’article.

Cependant en début de projet, vous n’avez aucune idée de la capacité de faire ; je vous conseille donc de demander aux développeurs de proposer un premier sprint qu’ils seraient capables de réaliser afin d’obtenir une idée de la capacité de faire du premier sprint. On en déduira la capacité de faire de chacun des sprint de la 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.

Déterminer un planning release

Voici par exemple la représentation sous forme de board de notre planning release très simple à réaliser :

Avec ce type de board, on comprend vite l’avancement du travail qui est attendu. Cependant, sur un projet agile, on sait que le scope pourra sans soucis changer avec le temps et que la base de l’exercice est d’aller chercher une date d’atterrissage, de définir les ressources techniques nécessaires ou de valider une date imposée et non de planifier des mois de travail.

Rappelons seulement qu’il faudra respecter la capacité de développement de chaque sprint pour faire ce type de board.

Sprint 1 = 30 complexité d’autorisées
le Sprint 2 = 33 complexité d’autorisées
Sprint 3 = 32 complexité d’autorisées
le Sprint 4 = 25 complexité d’autorisées
Total de la release = 120 complexités

Si vous avez une deadline pour votre release, vous pourrez alors voir si il vous sera nécessaire de retirer des demandes à la release ou si vous êtes bon côté capacité de production.

En cas de besoin de retirer des demandes, il faudra respecter prioritairement les objectifs de la release pour faire des choix.

Suivi de la release (planning release)

En général, on met également en place un Burndown Chart de release qui permettra de voir comment notre release avance sur le temps. Si on fait un suivi quotidien, on pourra rapidement savoir si le projet prend du retard ou non par rapport à l’estimation de départ.

Si le scope se modifie avec le temps ce qui est censé être le cas, n’oubliez pas de mettre à jour votre Burndow Chart Release. Il est essentiel de ne pas se bloquer au scope initial.

La release prend du retard (planning release)

Si l’équipe n’a pas su délivrer autant de demandes que prévues (demandes en Done), il va falloir faire un choix sur la stratégie à prendre :

1/ Soit  revoir l’atterrissage de notre release et d’aller sans attendre prévenir les stackholders ou managers impactés.

2/ Soit adapter le contenu du backlog de notre release pour pouvoir toujours livrer à la date attendue au risque de dégrader le contenu de la release.

Cependant en agile, on privilégierais la deuxième méthode car un scope vit constamment et n’est jamais constant. Certains feront une exception si il y a un MVP (Minimum Viable Product) définit et qu’il n’est pas atteint.

Voici comment marquer le nouvel atterrissage sur un Burndown Chart :

Conclusion : planning release

Vous avez maintenant tous les éléments en main pour être capable de faire une planning release avec vos équipes. N’hésitez pas si vous avez des questions sur ce planning release.