Qu’est-ce qu’un plan de livraison Scrum ?

Le but d’un plan de livraison est de préciser quand diverses fonctionnalités ou le produit seront livrés au client, permettant ainsi au Scruméquipe de communiquer la feuille de route et le calendrier de livraison du produit en cours de développement. Grâce à une planification à long terme, l’équipe peut répondre aux attentes du Product Owneret des parties prenantes du projet, et aider à répondre à des questions clés telles que :

• Quand serons-nous prêts ?
• Quelles fonctionnalités puis-je avoir à la fin de l’année ?
• Combien cela coûtera-t-il ?
• Identifier les dates clés et les jalons
• Coordonner les calendriers de développement des systèmes dépendants
• Aider à équilibrer la valeur commerciale et la qualité globale dans les contraintes de portée, de calendrier et de budget

Modèles de planification de livraison

De nombreuses organisations ont leur propre rythme pour livrer des produits aux clients. Certaines choisissent de livrer après chaque Sprint. D’autres regroupent les résultats de plusieurs Sprints dans une seule version, comme indiqué dans le schéma ci-dessous. D’autres livrent immédiatement après la finalisation de chaque fonctionnalité — cette approche est couramment appelée déploiement continu ou livraison continue.

Définition de prêt

Un plan de livraison est une feuille de route qui reflète les attentes concernant les fonctionnalités à implémenter et leur date de finalisation. Selon la stratégie de développement, il peut être orienté fonctionnalités — où l’objectif est de livrer une version une fois qu’un ensemble prédéfini de fonctionnalités est développé — ou orienté date, où la livraison a lieu à un point de contrôle prédéfini. Si le projet est orienté fonctionnalités, la somme totale de toutes les fonctionnalités d’une livraison peut être divisée par la vitessepour estimer le nombre de Sprints nécessaires pour finaliser les fonctionnalités demandées.

Avez-vous besoin d’un plan préalable à la livraison ?

La planification de livraison est un sujet controversé dans Agile. Bien que nous soyons souvent amenés à fournir des prévisions concernant le coût et le calendrier dans le monde des affaires, Scrum ne recommande pas la création d’un plan de livraison rigide et prédéfini. Voici quelques arguments contre la planification préalable :

• Les clients voient souvent peu de valeur dans les plans de livraison et les considèrent comme une perte de temps
• Les changements rapides dans de nombreux domaines valident le principe « Vous n’aurez pas besoin de cela » (YAGNI) — ce qui signifie que prévoir les livraisons est inutile
• Ainsi, la seule valeur d’un plan de livraison pourrait être la date initiale et le budget — rien d’autre

Pourquoi avons-nous encore besoin de la planification de livraison ?

Néanmoins, les dates réelles de livraison dans les environnements Agile tombent souvent en dessous des objectifs promis. Toutefois, disposer d’une feuille de route générale de livraison peut renforcer la confiance et fixer les attentes entre votre équipe et les parties prenantes. En outre, une livraison doit tenir compte de tous les travaux supplémentaires à accomplir, tels que la mise à jour des sites web publics et la formation des équipes de support client. Voici les principales raisons de réaliser une planification de livraison dans Scrum :

• Communication
• Outil de planification
• Valider la valeur par rapport au coût
• Définir le contexte général

Exemple de planification de version :

Les plans de version se présentent sous de nombreux formats. Voici un exemple pour la planification axée sur les fonctionnalités/données :

Exemple de planification de version

Si le projet est piloté par une date, nous pouvons simplement multiplier la vitesse par le nombre de sprints pour déterminer le volume total de travail pouvant être accompli dans une période donnée.

Planification de version pilotée par la vitesse

Un plan de version n’est pas un document statique — il doit être réexaminé et mis à jour régulièrement au fur et à mesure que nous gérons notre Product Backlog. Lorsque de nouvelles informations deviennent disponibles (par exemple, les entrées du Product Backlog Scrum sont mises à jour ou ajustées), le plan de version doit être réexaminé et révisé en conséquence.