Planifier la release
Pourquoi prévoir à un horizon plus lointain que le sprint ?
Dans l’édition 4 de mon livre Scrum, la présentation de la planification de release a été repoussée. Planifier la release constitue maintenant le chapitre 16. Dans les éditions précédentes, elle était présentée avant la planification de sprint. Cette décision de déplacer ce sujet m’a demandé beaucoup d’efforts, d’autant plus que j’en ai profité pour revoir une grande partie du contenu de l’édition 3, en intégrant des notions nouvelles inspirées du courant #noEstimates.
La raison principale de ce changement est que planifier la release est une pratique optionnelle. On peut s’en passer. On peut surtout mieux en faire, car il arrive assez souvent qu’on en ait besoin.
Voici un extrait de mon livre, page 198, qui présente des situations où prévoir plus loin que le sprint est utile.
Prévoir pour préparer le déploiement du produit
La release est une série de sprints. Nous avons vu à quoi servait la planification de sprint et comment elle se déroulait. Planifier la release, c’est essayer de prévoir le résultat à la fin de cette série. L’horizon est plus lointain.
À quoi cela sert ? D’abord, si le déploiement coïncide avec la fin de release, à informer les parties prenantes, qui attendent le produit ou y contribuent.
Prévoir pour se synchroniser
Le déploiement auprès des utilisateurs finaux ne se fait pas toujours en fin de la release :
- d’un côté, il y a des systèmes industriels pour lesquels le déploiement ne se fera peut-être qu’après plusieurs releases ;
- d’un autre côté, pour des applications web, le déploiement peut être fait plus fréquemment, à chaque fin de sprint, voire plus souvent en cas de « déploiement continu ».
Ceci étant dit, quel que soit le type de déploiement auprès des utilisateurs finaux, la planification de release reste une pratique permettant de prévoir des points de rencontre avec des parties prenantes, notamment pour obtenir leur feedback, ou pour se synchroniser avec d’autres équipes.
La planification de release ne concerne pas que l’échéance finale. Prévoir les prochains sprints est utile pour définir les synchronisations nécessaires avec d’autres équipes ou d’autres personnes.
Prévoir pour décider
La meilleure façon de procéder pour la release est de définir une date de fin et de s’y tenir, en reprenant l’idée de la timebox, comme pour le sprint.
La release à date fixée définit le budget à l’avance et un horizon pas trop lointain, ce qui impose au PO de prendre des décisions :
- sur les priorités des éléments du bac d’affinage ;
- sur la purge de stories ne présentant finalement que peu d’intérêt.
Le plan de release, en présentant la situation lors de la revue de sprint, permet de prendre des décisions avec les parties prenantes sur l’avenir du produit.
Avant de passer du temps à planifier une release, il convient de définir quel objectif on poursuit. Le niveau de précision du plan de release dépend de l’objectif. Le connaître permet d’éviter, par exemple, de longues séances de Planning Poker, alors que compter suffit pour prendre la décision requise.
Peut-être serez-vous aussi intéressés par les compléments à la planification de release pour l’édition 3.