---

Qu’est-ce qu’un plan de livraison Scrum ? La réponse pourrait vous surprendre !

Un plan de livraison vise à visualiser la planification globale de plusieurs Sprints, généralement entre trois et douze dans cet exemple. Les Sprints ont une durée fixe ; un incrément est un résultat utilisable, et plusieurs incréments peuvent être créés au cours d’un Sprint.

Le plan de livraison sert de ligne directrice et reflète les attentes envers une Scrum Team concernant :

• Les fonctionnalités qui seront réalisées,
• L’ordre et le moment de leur réalisation.

Le plan de livraison sert aussi de référence pour suivre et maîtriser l’avancement du projet. Il fixe une cible pour les déploiements réels dans les systèmes informatiques de production, de deux façons :

• Le déploiement de « livraisons jalons » pour créer de la valeur pour le client avant la fin du projet. Elles couvrent un sous-ensemble des exigences du client convenu entre le Scrum Product Owner, le client et les parties prenantes métier,
• Le déploiement de la livraison finale, qui comprend toutes les demandes et fonctionnalités connues du client et des parties prenantes métier.

Avant de créer un plan de livraison, il faut prendre en compte les artefacts et informations suivants :

• Un Scrum Product Backlog ordonné par priorité et estimé,
• La vélocité mesurée de la Scrum Team (si elle vient de se constituer, la vélocité est estimée ou extrapolée à partir de projets similaires passés),
• Les critères de réussite imposés par les clients, comme le calendrier, le périmètre et les personnes disponibles dans le budget du projet.

Le plan de livraison étant étroitement lié au Product Backlog, le Scrum Product Owner le pilote et le tient à jour.

Selon les demandes et les priorités des clients, le plan de livraison poursuit l’un de ces trois objectifs :

• Planification des livraisons fondée sur les fonctionnalités
• Planification des livraisons fondée sur la date
• Planification des livraisons fondée sur les fonctionnalités et la date (La plus courante)

Planification des livraisons fondée sur les fonctionnalités

Ce que nous savons : La vélocité de la Scrum Team et les fonctionnalités à livrer.
Ce que nous ignorons : Combien de temps faut-il pour livrer ces fonctionnalités ?

Pour les plans de livraison fondés sur les fonctionnalités (en savoir plus sur La planification des livraisons Scrum), la somme des points des user stories correspondant aux fonctionnalités demandées est divisée par la vélocité de l’équipe. Cela fournit une première estimation du nombre de Sprints nécessaires pour une livraison jalon ou finale. Arrondissez au Sprint entier supérieur et réévaluez les hypothèses de périmètre et de vélocité au fil du travail. Le plan de livraison est établi en conséquence.

Planification des livraisons fondée sur la date

Ce que nous savons : La vélocité de la Scrum Team et la date souhaitée de livraison.
Ce que nous ignorons : Quelles fonctionnalités pouvons-nous livrer avant l’échéance ?

Pour les plans fondés sur la date, nous multiplions la vélocité de l’équipe par le nombre de Sprints disponibles avant la date de livraison. Nous obtenons le nombre total estimé de points de user stories que la Scrum Team peut livrer d’ici là, puis établissons le plan en conséquence.

Planification des livraisons fondée sur les fonctionnalités et la date

Ce que nous savons : La vélocité de la Scrum Team, les fonctionnalités à livrer et la date souhaitée de leur livraison.
Ce que nous ignorons : La Scrum Team peut-elle livrer les fonctionnalités demandées avant l’échéance fixée ?

Nous multiplions la vélocité de l’équipe par le nombre de Sprints disponibles avant la date de livraison. Nous obtenons le nombre total estimé de points de user stories que la Scrum Team peut livrer d’ici là. Si ce nombre dépasse la somme des points des fonctionnalités de la version, la prévision actuelle suggère que le périmètre est réalisable ; elle reste soumise à l’incertitude et aux changements.

Sinon, discutez des compromis entre périmètre, date et capacité. Ajouter des personnes n’augmente pas automatiquement la vélocité et peut d’abord ralentir l’équipe pendant qu’elles apprennent à collaborer. L’ancienne recommandation de neuf personnes n’est pas une limite actuelle stricte : une Scrum Team compte généralement 10 personnes ou moins. Une autre Scrum Team peut travailler en parallèle si cela améliore l’efficacité ; les équipes travaillant sur le même produit partagent toujours un Product Owner, un objectif de produit, un Product Backlog et une définition de fini.

Comme le Scrum Product Backlog, le plan de livraison évolue pendant tout le projet à mesure que nous en apprenons davantage. Les user stories ajoutées, supprimées ou modifiées et les changements de leurs estimations influencent aussi les plans de livraison. Le plan doit donc être réexaminé et actualisé régulièrement.