Release Plan

La présente page vous guide dans le déroulement de l’atelier de mise à jour et alimentation du Backlog « Release Plan ».

Il n’y a pas de template spécifique à cet atelier.

Si vous n’êtes pas encore membre, découvrez notre kit de l’agilité. Ne manquez pas l’opportunité de l’acquérir et de profiter de tous les avantages qu’il peut apporter à votre gestion de projet agile.

Objectif du livrable

Le Release Plan ou Plan de Livraison, déploie la vision produit à travers la définition des releases du produit identifiées à date. 

Ce plan reprend le contenu du Product Backlog avec différents niveaux de granularité pour le court, moyen et long terme.

Le Release Plan est élaboré en tenant compte de la capacité de l’équipe pendant les Sprints/Itérations et des contraintes techniques, réglementaires, etc. 

Il offre une vue d’ensemble sur les dates de lancement des différentes versions du produit, facilitant ainsi l’alignement avec le Time-to-market et les étapes clés du projet.

Déblocage des macros

Avant d’ouvrir un fichier Excel, pensez à débloquer les macros.

Pour ce faire, faites un clic droit sur le fichier avant de l’ouvrir. Ensuite choisissez Propriétés, puis activez la case à cocher Débloquer sous l’onglet Général.

Ceci afin d’éviter d’avoir un message rouge à l’ouverture d’un fichier Excel :

Activation des macros

Pour s’assurer du bon fonctionnement du template, vérifiez que les macros sont activées :

Quand utiliser ce livrable ?

La première version du Release Plan est réalisée à la fin de la phase de cadrage même si un Macro-planning peut-être réalisé plus tôt durant la phase d’opportunité.

Le Release est ensuite utilisé durant la phase d’exécution pour planifier les travaux des Sprints/Itérations.

Il est régulièrement mis à jour à la fin de chaque Sprint pour revoir les priorités et planifier les travaux restants. 

En outre, au cours des ateliers métiers, le Product Owner collabore avec les experts du domaine pour ajouter, modifier ou supprimer des composants du produit, ce qui influence directement le Plan de Publication.

Comment utiliser ce livrable ?

Lors du cadrage :

1. La première version du Release Plan est créée en se basant sur la priorisation des composants produits définis dans la Roadmap Produit, la Story Map et le Backlog Produit
2. Pour planifier les travaux de manière efficace, le Release Plan se base sur 2 éléments clés :
   1. Une hypothèse sur la capacité de l’équipe, qui détermine le nombre de points d’effort que l’équipe peut fournir lors de chaque sprint
   2. Ainsi que la durée des Sprints/Itérations
3. Le Release Plan peut être initié par le Scrum Master et le Product Owner, puis fera l’objet d’ateliers avec différentes parties prenantes métiers, techniques etc. afin d’intégrer toutes les contraintes et prérequis dans la planification

Durant la phase d’exécution :

1. Le Release Plan est consulté par le Product Owner et l’équipe pour planifier un Sprint/Itération
2. Le Release Plan est présenté lors de la Sprint Review pour examiner l’impact de l’avancement du Sprint, mais aussi pour échanger avec les différentes parties prenantes sur les changements concernant le produit et comment les intégrer
3. Au fil des Sprints/Itérations, le Release Plan est détaillé sur un horizon de 6 à 12 mois

Structure du document

 Le Release Plan est constitué de 2 sections :

1. Informations :

• Nom du produit
• Durée des Sprints
• Date de mise à jour

2. Planning des activités de développement des initiatives, Epics et activités de Mise en production par releases, et sprints :

• Ligne Année : Année concernée dans le cas d’une Roadmap sur plus d’une année
• Ligne Mois : Mois concernés
• Ligne Versions : Précise la version du produit en cours de développement
• Ligne Releases : Place les releases de la version produit identifiées à date
• Ligne Sprints : Identifie le nombre des Sprints nécessaires pour chaque release
• Ligne Capacité en pts : Estime la capacité de l’équipe en points en prenant en considération les jours fériés, les congés et autres contraintes qui impacte la capacité de l’équipe
• Ligne produit : Liste les Initiatives, les  Epics et les améliorations qui seront développés durant un Sprint
• Ligne”Prérequis” : Liste des prérequis internes à l’équipe pour démarrer les travaux par l’équipe de développeurs ( ex: enrichir une US (user story) par des règles de gestion, concevoir une interface UI)
• Ligne “Dépendances” : Liste des dépendances avec des équipes externes (ex : disponibilité d’un environnement utilisé par une autre équipe, ouverture de flux entre des environnement pour faire des tests…)
• Ligne MEPP (Mise en pré-production) : Liste des activités nécessaires à la mise en pré-production d’une release du produit dans un environnement de test  pour démarrer les UATs (User Acceptance Tests)
• Ligne UAT (User Acceptance Test) : Liste des activités de recette fonctionnelles par les métier pour l’acceptation de la release du produit
• Ligne MEP (mise en production) : Liste des activités nécessaires à la mise en production et la mise en service  d’une release du produit dans l’environnement de production