Fiche 06 : La planification de la release

Un plan de release est une séquence de sprints à venir, avec une vision du contenu prévu (les éléments de backlog de produit) de ces sprints. Présenté sous forme de tableau, un plan de release est facile à comprendre pour les clients et utilisateurs. Les sprints sont présentés de façon séquentielle de gauche à droite, avec pour chacun son numéro, son but, sa vélocité prévue et ses dates de début et fin. Les éléments du backlog associés à chaque sprint sont estimés en points, et différenciés en fonction de leur nature (user story, story technique ou défaut). Il leur donne un bon aperçu des différents incréments de produit qui vont être développés dans le temps.

Planning des sprints à venir

Pourquoi l'utiliser ?

Objectif

• Planifier le projet à moyen terme.
• Mesurer la capacité de l'équipe à réaliser les stories du backlog dans les temps.
• Donner de la visibilité au propriétaire du produit et aux utilisateurs sur la livraison des stories.

Contexte

Le plan de release est construit une première fois dès qu'une première version du product backlog existe, et il est mis à jour à chaque sprint.

Comment l'utiliser ?

Étapes

• S'assurer que la première version du backlog est disponible. Il faut souvent plusieurs réunions pour stabiliser ce backlog, avant de se lancer dans le processus de planification de la release.
• Réunir toute l'équipe Scrum (dont product owner et Scrum master) : ce sont ceux qui seront chargés de la réalisation des stories qui sont les mieux placés pour planifier cette réalisation !
• Définir la fin de la release. Terminer la release quand le backlog est vide : l'idée est noble, mais le problème, c'est que le backlog évolue en permanence ! Terminer la release quand un sous-ensemble du backlog est vide : cela permet de se focaliser sur les stories jugées prioritaires, et d'affecter les stories suivantes à une autre release. Terminer la release lorsque le produit partiel qui a été développé a suffisamment de valeur, ou quand le budget est consommé. Fixer une date de fin à l'avance : c'est un bon moyen de motiver l'équipe et les utilisateurs, et favorise le travail de priorisation. Estimer les stories du backlog à l'aide du planning poker. Définir la durée des sprints : on privilégie les sprints courts (1 à 2 semaines quand cela est possible !). Estimer la vélocité (partie de backlog, estimée en points, et réalisée par l'équipe pendant le sprint) et la capacité (prévision de ce que l'équipe sera capable de faire pendant le sprint suivant).
• Dessiner le plan de release : " remplir " le premier sprint avec les stories du backlog (en commençant par les plus prioritaires), en additionnant la taille en points de chaque story, jusqu'à arriver à la capacité de l'équipe. Passer ensuite au sprint suivant !
• Utiliser un support visuel pour représenter le plan de release et en faire un véritable outil de communication avec le product owner et les utilisateurs.
• Actualiser la release un peu avant la fin de chaque sprint.

Méthodologie et conseils

Lorsque la release intègre de nombreux sprints, il est conseillé de planifier ces derniers " par vagues " : détailler les stories des deux ou trois sprints à venir, et accepter que les stories suivantes restent macroscopiques. Elles seront détaillées à leur tour lorsque l'équipe aura fait un bout de chemin sur les premiers sprints.