Le plan de release, ce grand oublié d’un grand nombre d’implémentations agiles. Non pas qu’il a été oublié de Scrum, simplement de ceux qui le mettent en place. C’est un constat personnel de mes dernières années de coaching agile.

La bonne nouvelle est que les organisations se penchent enfin sérieusement sur le rôle du Product Owner et de ses pratiques. Je le vois principalement avec le nombre plus important de missions autour de ce rôle. Il y en avait bien sur avant, mais la proportion augmente.

La mauvaise nouvelle est que le niveau n’est globalement pas très élevé, et qu’il manque des fondamentaux. Je ne parle pas de la maîtrise du produit lui-même, mais bien du rôle. La bonne nouvelle de la mauvaise nouvelle est qu’il y a une marge de progression intéressante à aller chercher pour ces organisations pour gagner en agilité (et donc en valeur ajoutée, en Feedback, en délai, …).

Et un des fondamentaux du Product Owner est le plan de release.

Aujourd’hui, donc, le plan de release

C’est quoi, en deux mots ?

Claude Aubry le définit comme :

la présentation des sprints à venir et du contenu prévu de ces sprints.

C’est à dire des user stories et à plus long termes des features qui, a priori, vont constituer le périmètre de la release du produit. C’est la ventilation du Product Backlog dans les futurs sprints de la release.

Plan de release

Un peu de contexte

Vous pensez qu’il n’est pas agile de piloter un plan de release ? Que ce n’est pas la peine de planifier quoi que ce soit en agile vu que le contenu peut changer en cours de route ?

Vous n’êtes pas les seuls, voici les raisons, que je rencontre souvent, justifiant le manque de plan de release :

• Le Product Owner ne sait pas que ça existe (et d’ailleurs, lui ou ses sponsors se plaignent du manque de visibilité et de pilotage de l’agilité au-delà des sprints).
• Il juge suffisant d’avoir défini des user stories pour le prochain sprint.
• Définir vaguement quelques epics pour la release suffit…
• Le plan de release est du pilotage de projet, et il pense donc que c’est au Scrum master de le faire (pas à juste titre). Surtout il le fait en mode client / fournisseur avec un scrum master ayant un rôle de chef de projet agile (mes doigts brûlent en écrivant cette ligne …).

Bref, passons…

A l’inverse, pensez-vous qu’il soit suffisant de donner de la visibilité sur quelques semaines seulement (la durée d’un sprint) alors qu’on parle de vision produit et de gestion de projet (même agile) ?

C’est justement là que se positionne le plan de release. Donner un niveau de pilotage intermédiaire entre la roadmap et le sprint.

Donc ce n’est pas pour moi

Bien que cette pratique ne fasse pas partie directement de Scrum, c’est souvent utile… Mais dans certains cas, on peut s’en passer :

• En phase de MCO, petits évolutifs / correctifs avec l’application en production. Le Kanban va prendre la relève pour aider à piloter le flux de travail.
• Lorsque le contexte est très exploratoire, proche d’un MVP au sens du Lean startup, il serait contre-productif de faire un plan de release.
• Pour un projet en co-construction avec une forte part d’émergence.
• Dans le cas d’un petit projet de quelques sprints, qui n’aura pas de suite. Par contre, si vous enchaînez des petites releases sur un même projet, voire vous déployez régulièrement, vous pouvez utiliser un plan de release sur une fenêtre glissante de quelques sprints.

On le voit, les contextes projets ou le plan de release n’a pas d’intérêt ne sont pas légions. Et à l’inverse, l’essentiel des projets que je croise aurait intérêt à mettre en place ce niveau de pilotage.

Le plan de release

Niveaux Pilotages

Il existe plusieurs niveaux de granularité :

• La vision produit : elle n’est pas spécifique à l’agilité, elle s’inscrit dans la vision stratégique de l’entreprise. Le besoin en vision produit est renforcé par le fait de piloter du changement, pour garder l’objectif final en tête.
• La roadmap : de même, ce n’est pas un niveau spécifique de l’agilité. C’est l’enchaînement des releases du produit. Comme l’agilité tend à réduire le périmètre des versions, pour mettre en production très régulièrement, cela augmente l’intérêt, voire la nécessité, de construire une roadmap. Cela reste des informations au niveau stratégique. La roadmap fixe le cadre de la prochaine release du produit.
• Le plan de release : à l’intérieur de ce cadre stratégique, le Product Owner pilote le périmètre (user stories, features) de la version de manière à maximiser la valeur ajoutée (satisfaction utilisateur, taux d’adoption, …). A ce stade il ne pilote que des options, pas d’engagement à les réaliser, mais un engagement à adresser les besoins / attentes auxquels elles répondent.
• Le plan de sprint : c’est le pilotage quotidien. C’est le domaine de l’équipe. On parle user stories et tâches techniques. Cette fois un engagement sur le périmètre a été pris par l’équipe en début de sprint, pas avant.

Comment piloter la release ?

Le plan de release est un outil de pilotage des user stories qui vont effectivement faire partie du périmètre mis en production. Toutes les stories du Product Backlog ne seront finalement pas implémentées. C’est la magie de l’agilité : savoir piloter du changement, tout en cherchant à minimiser le coût de ce changement.

Or le coût augmente fortement à mesure que l’on rentre dans le détail (des exigences, des specs, du code, des tests, …). Donc un des principes de l’agilité pour minimiser le coût du changement est d’aller dans le détail le plus tard possible (simple), mais pas trop tard (plus dur).

Alors pour prendre les bonnes décisions de pilotage (priorisation, arbitrage) en tant que Product Owner, il doit avoir une information suffisante sur le coût des stories ou des features. Cette information n’a pas besoin d’être très précise. On est au niveau de la release. On pilote ici des options, On ne cherche pas à s’engager sur un périmètre de sprint.

Estimer précisément nécessite d’aller dans le détail, soit fonctionnel soit technique. Cela coûte du temps et c’est trop tôt, surtout lorsque l’on n’a pas la certitude d’effectivement implémenter la story. Donc on va estimer à la louche.

D’autre part, le principe du pilotage de Scrum est de piloter sur la base d’un logiciel qui fonctionne (c’est une des 4 valeurs du manifeste agile), donc sur la base des stories finies. Les estimations doivent prendre en compte toutes les activités permettant de finir une story, y compris les tests métier, le mûrissement, la conception fonctionnel…

Certaines de ses activités sont réalisées par le Product Owner et/ou les analystes business. C’est pourquoi ils estiment aussi les stories. Et pour que tout le monde puisse estimer, on le fait de manière relative, une story par rapport à une autre.

Je sais que les estimations font toujours débat dans le développement logiciel, et surtout dans la communauté agile. Je ne me jetterais pas à corps perdu dans ce débat, car à mon sens il est bien plus subtil que ce que je lis sur le sujet. Il ne faut pas confondre la cible, et la transition pour y arriver. J’espère juste recadrer l’utilisation des estimations agiles, en points, pour ceux qui les utilisent.

Les estimations relatives répondent très bien à ce double enjeu : que tous les acteurs estiment, en y passant juste le temps nécessaire pour avoir une information suffisante, pour que le Product Owner puisse prendre de bonnes décisions au niveau du plan de release.

Voilà l’objectif premier des estimations en points. Il se trouve que si le nombre de points réalisés par l’équipe à chaque sprint est stable, la vélocité, alors c’est une information qui peut suffire à l’équipe pour définir le périmètre d’un sprint et s’engager. Sinon, l’équipe s’engagera sur la base de sa capacité.

Retour au plan de release

Une fois que les stories du backlog sont estimées (lors du sprint 0 puis lors des séances de grooming), les points servent au pilotage de la release. C’est le burndown de release, qui n’est ni plus ni moins un indicateur de reste à faire, sur la base du nombre de story points (SP) restant dans le backlog.

Burndown chart release

A vous de jouer !

Tout cela pour dire qu’il y a tout ce qu’il faut pour piloter des projets agiles, au-delà des sprints, que le plan de release existe, avec son indicateur. Et que bien que souvent nécessaire, il est malheureusement rarement utilisé.

Alors, les Product Owners, à vos plans de release !

PS : je vous renvoie au chapitre du livre de Claude Aubry pour plus d’informations sur le plan de release.

Et si vous passiez aux OKRs ?

Et oui, construire le plan de version c’est bien, nous l’avons vu. Mais comment le faire ? Je vous propose de regarder du côté des OKRs, pour  objective & Key Results. C’est une méthode très intéressante en amont de la roadmap (avec les objectifs produit stratégiques) et le plan de release (avec les objectifs produit tactiques). J’évoque le sujet dans cet article.