Calculer le nombre de sprints nécessaires pour aller au bout d'un projet est intéressant pour une question de prédictibilité.
Cela permet au client d'avoir une date d'atterrissage estimée pour le projet agile, et à l'équipe Scrum de savoir quelle charge de travail elle peut absorber sur un sprint.
Nous allons voir dans cet article comment estimer le nombre de sprints nécessaires pour réaliser un projet agile, exemple à l'appui.
Quelques rappels de notion
Avant de commencer, il est nécessaire de connaître et comprendre les notions agiles ci-dessous, vu que nous allons nous baser dessus pour la suite de l'article.
1 ) Vélocité
C'est un indicateur de mesure qui indique combien de points d'efforts l'équipe est en capacité de fournir sur chaque sprint. Elle se mesure à la fin de chaque sprint.
2 ) Story points
Les story points, ou points d'efforts, remplacent les estimations jours-homme dans les méthodologies de gestion de projet classiques. Ils permettent d'estimer l'effort nécessaire pour réaliser un travail donné, et se mesure le plus souvent via la suite de Fibonacci, ou les tailles de tshirt.
3 ) Sprint backlog
Le sprint backlog est l'ensemble du travail à réaliser dans le cadre d'un sprint, sélectionné par l'équipe de développement afin d'atteindre un objectif de sprint précis.
4 ) Definition of done
La definition of done, ou définition de fini, est une checklist qui indique ce qu'est pour l'équipe un travail vraiment terminé à 100%. Tous les éléments du sprint backlog doivent être terminés selon cette définition pour être livrés aux parties prenantes.
5 ) Product backlog
Le product backlog est une liste ordonnée des éléments que l'on aimerait bien développer dans de futurs sprints, priorisés en fonction de leur valeur. Le product backlog est vivant, il émerge au fil du temps, et évolue constamment.
Comment estimer le nombre de sprints nécessaires pour un projet agile ?
Calculer le nombre de sprints nécessaires pour traiter l'intégralité du product backlog et réaliser le produit est relativement simple, à condition de respecter les étapes suivantes :
- Tous les éléments du product backlog doivent être estimés.
Cela permet d'estimer l'effort nécessaire pour l'équipe afin d'aller au bout du backlog de produit. Vous pouvez utiliser pour cela le planning poker. - La vélocité de l'équipe doit être connue.
Référez-vous à l'article sur la vélocité agile pour savoir comment la calculer. - Faites une division élémentaire.
Divisez la somme des estimations des éléments du product backlog par la vélocité de l'équipe. - Arrondissez au chiffre supérieur.
Arrondissez le résultat au chiffre supérieur, et vous obtenez une assez bonne idée du nombre de sprints nécessaires pour réaliser votre projet. - Gardez à l'esprit qu'il s'agit d'une estimation, pas d'un engagement.
Le product backlog peut évoluer à la hausse ou à la baisse entre temps, cette estimation n'est donc pas gravée dans le marbre.
L'équipe Scrum s'engage sur la qualité, à savoir le respect de la definition of done, et sur le fait de livrer un incrément à la fin de chaque sprint. Elle ne s'engage pas sur la quantité de travail à accomplir, ni sur le nombre de sprints nécessaires.
Exemple et cas concret
Imaginons que l'équipe Scrum a eu une vélocité de 42, 36, et 41 sur les trois derniers sprints. La vélocité moyenne est donc de :
Vélocité moyenne = (42 + 36 + 41) / 3 = 39,66, soit 40.
L'équipe de développement est donc en capacité de fournir l'équivalent de 40 points d'efforts au cours d'un sprint. Elle peut donc absorber dans son sprint backlog des user stories dont la somme représente 40 story points.
Imaginons maintenant que la somme des éléments dans le product backlog représente 788 points d'efforts.
Le nombre de sprints nécessaires sur ce projet serait donc de :
Nombre de sprints = 788 / 40 = 19,7, soit 20 sprints une fois l'arrondi réalisé.
A la vélocité actuelle, l'équipe Scrum aura donc besoin de 20 sprints pour aller au bout du product backlog actuel.
Cela donne une bonne idée, mais on peut encore affiner cette estimation en calculant la capacité d'un sprint.
En effet, on a considéré dans notre calcul que les sprints étaient égaux : 5 jours ouvrés, sans jours fériés, sans absences dans l'équipe. Mais dans la réalité, il en est tout autrement.
Quel est l'intérêt de prédire le nombre de sprints ?
"Je croyais que l'agilité, c'était arrêter de vouloir tout prévoir, et de travailler en itérations courtes jusqu'à avoir le produit final. Quel est l'intérêt alors d'un tel calcul ?"
Calculer le nombre de sprints nécessaires pour réaliser le product backlog est utile notamment pour construire des roadmaps produit fiables.
Bien qu'on puisse s'en passer, les roadmaps sont souvent attendues par les directions et managers hiérarchiques qui n'ont pas encore réussi à adopter complètement l'état d'esprit agile.
