Calculer la vélocité d'une équipe est un indicateur de prédictibilité intéressant, mais trop incertain. C'est pourquoi je vous recommande de calculer la capacité d'un sprint.
Cette notion vous permettra de déterminer avec exactitude la charge de travail que l'équipe pourra absorber lors d'un sprint, de façon bien plus précise que la vélocité.
Je vous explique tout ça dans l'article.
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 calculer la capacité d'un sprint ?
On est ainsi en mesure de prendre en compte les absences (congés, arrêts maladie, etc).
La capacité d'un sprint se calcule ainsi :
Capacité = ∑ (SP3) / ∑ (Jho3) * Jhof
- ∑ (SP3) est la somme des story points (points d'efforts) réels des user stories en done des 3 précédents sprints. C'est donc la somme des trois précédentes vélocités.
- ∑ (Jho3) est la somme des jours/homme de présence des développeurs de l'équipe sur les 3 précédents sprints.
- Jhof est le nombre de jours/homme de présence estimé sur le prochain sprint. Il est calculé en fonction des absences des membres de l'équipe de développement.
On peut ainsi calculer le nombre de points d'efforts que l'équipe de développement est en mesure de faire sur le prochain sprint, en fonction du nombre de jours travaillés qu'ils auront.
Exemple et cas concret
Imaginons l'exemple ci-dessous.
Les trois dernières vélocité de l'équipe sur les trois derniers sprints sont les suivantes : 42, 36, et 41.
∑ (SP3), la somme de ces 3 vélocités est donc égal à 42 + 36 + 41 = 119.
Calculons maintenant le temps de présence de l'équipe par sprint. Pour cela, on considère que les sprints ont une durée de 2 semaines, et que l'équipe de développement est composée de 5 personnes.
- Sur le premier sprint, l'équipe était au complet, on a donc 10 jours ouvrés (2 semaines), ce qui nous donne un temps de présence à 10 * 5 = 50 jours/homme.
- Sur le second sprint, un développeur était absent pendant 3 jours, ce qui nous donne un temps de présence à 10 * 5 - 3 = 47 jours/homme.
- Sur le troisième sprint, tout le monde était présent, mais il y a eu un jour férié au milieu du sprint, ce qui nous donne un temps de présence à 10 * 5 - 1 * 5 = 45 jours/homme.
∑ (Jho3), la somme des jours de présence sur les trois derniers sprints est donc de 50 + 47 + 45 = 142.
Bien. Maintenant voyons un peu ce qui se passe sur le prochain sprint.
- 1 développeur est en congés pendant deux semaines, et 1 autre pendant 1 semaine. Cela nous donne un temps de présence estimé à 10 * 5 - 10 - 5 = 35.
Calculons enfin la capacité de l'équipe sur ce sprint :
Capacité = 119 / 142 * 35 = 29,3, soit 29.
L'équipe de développement sera donc en mesure de prendre en compte 29 story points lors du prochain sprint, en tenant compte des absences de l'équipe.
Si on n'avait tenu compte que de la vélocité sans se préoccuper du temps de travail réel de l'équipe, on aurait attribué 40 points d'efforts lors du prochain sprint, ce que l'équipe n'aurait pas été en capacité de faire.
Et si une user story est réestimée en cours de route ?
Il nous reste un cas particulier à traiter, qui peut influer sur le calcul de la vélocité de l'équipe et de la capacité d'un sprint, donc du nombre de sprints nécessaires sur un projet.
Que se passe t-il lorsqu'une user story est ré-estimée à la hausse ou à la baisse en cours de route ? C'est notamment le cas d'une user story qui n'a pas pu être terminée sur le sprint précédent, et qui est réévaluée par rapport au reste à faire.
1 ) Réévaluation à la baisse
Imaginons que la user story était estimée à 8 lors du sprint 2, et qu'elle a été réévaluée à 5 lors du sprint 3. Le post-it devra le refléter comme ceci :
Vu sur myagilepartner.fr
Lors du calcul de la vélocité du sprint, on prendra en compte le point d'effort initial, soit 8.
Pourquoi ? Car au total, l'équipe aura réalisée 8 points d'effort, mais sur deux sprints. Il est donc important de le représenter.
Pour calculer la capacité d'un sprint, on prendra le second point d'effort, soit 5. Cela représente de manière plus juste le travail à réaliser par l'équipe dans le cadre de ce nouveau sprint.
2 ) Réévaluation à la hausse
Imaginons que la user story était estimée à 8 lors du sprint 2, et qu'elle a été réévaluée à 13 lors du sprint 3.
Lors du calcul de la vélocité du sprint, on prendra en compte le point d'effort le plus élevé, soit 13.
Ce point d'effort représente la somme du travail à effectuer.
Pour calculer la capacité d'un sprint, on prendra le point d'effort le moins élevée, donc le point d'effort initial, soit 8. Cela représente de manière plus juste le travail à réaliser par l'équipe dans le cadre de ce nouveau sprint.
3 bonnes pratiques dans l'utilisation de la capacité
Bien que cette notion de capacité de sprint soit utile pour prévoir le travail à réaliser, réaliser des roadmaps fiables et calculer le nombre de sprints nécessaires pour aller au bout d'un projet, ça ne doit pas s'utiliser n'importe comment.
Voici quelques bonnes pratiques à respecter :
1 ) Utilisez un calendrier sur votre Scrum board
Pour faciliter le calcul de la capacité de vos sprints et l'attribution des user stories dans le sprint backlog, je vous recommande d'afficher un calendrier avec les absences de l'équipe notées dessus.
2 ) Il ne s'agit que d'une estimation
Soyons clairs, la capacité d'un sprint est une estimation, un outil d'aide à la décision pour l'équipe de développement, afin de déterminer les user stories à intégrer au sprint backlog du prochain sprint.
Il ne s'agit pas d'une science exacte, et encore moins d'un engagement.
3 ) Ne faites pas l'amalgamme jours/homme = points d'efforts
Certaines personnes peuvent être tentées de faire le rapprochement jours/homme et points d'efforts, et de calculer qu'un story point est égal à tant de jours/homme.
C'est notamment le cas dans les directions, où les personnes sont moins sensibilisées à l'agilité. Elles cherchent donc un moyen de comparaison entre les anciennes méthodes de gestion de projet et Scrum.
Faire ceci, c'est pratiquer ce qu'on appelle du faux agile, et c'est dangereux car ça va vous ramener in extremis vers des méthodes prédictives, où l'estimation vaut engagement.
Le scrum master devra donc être le gardien afin d'éviter ce type de dérive.
