Quelques explications des différences entre la planification de la vélocité et de la capacité lors de vos sprints agiles lors d’un projet.
Au fil des ans, j’ai participé à de nombreux débats sur la façon dont la planification des sprints devrait être effectuée. Certains disent que la meilleure façon est de se fier à la vélocité de l’équipe. D’autres disent que non, nous devrions faire de la planification de capacité pour être plus précis et faire la bonne planification. Quelle est donc la bonne façon de planifier un sprint ?
Dans cet article, nous examinerons les différences entre la vélocité et la planification de la capacité, et nous discuterons également du type de planification qui convient aux différentes équipes. Dans un autre article, je vais décrire l’approche que je préfère utiliser pour la planification. Je fournirai également un outil (feuille de calcul Excel) pour organiser la meilleure réunion de planification possible.
Tout d’abord, discutons un peu de ce que sont la vélocité et la capacité.
- La vélocité est l’observation empirique des story points achevés dans les sprints précédents et est généralement mesurée comme une moyenne des story points réels achevés sur les N sprints précédents (je suggère généralement les 3-4 derniers sprints pour référence).
- La capacité est basée sur la disponibilité future prévue de l’équipe, généralement mesurée en heures. Cela peut varier en fonction de la disponibilité des membres de l’équipe pendant le sprint.
Plongeons dans la façon dont nous faisons les planifications de vélocité et de capacité.
Planification de la vélocité
Voici les étapes que les équipes réalisent habituellement pour une planification basée sur la vélocité :
- Calculer la vélocité moyenne (la meilleure pour les 3-4 sprints précédents)
- Sélectionner les histoires du backlog de produit dont la somme totale des points d’histoire est égale ou proche de cette vélocité moyenne.
L’un des inconvénients de la planification de la vélocité est qu’elle ne tient pas compte de la disponibilité des membres de l’équipe, mais cela peut aussi être résolu en projetant la disponibilité des membres de l’équipe sur la vélocité. Par exemple, considérons que l’équipe a 5 membres et que la vitesse moyenne est de 36, maintenant considérons que l’un des membres de l’équipe sera en vacances pendant tout le sprint, dans ce cas, nous pouvons calculer que la vitesse projetée du sprint actuel est égale à 36 * 4/5 = ~29 story points.
Un autre inconvénient ou la limitation de la planification de la vélocité apparaît lorsque l’équipe a différents rôles, tels que l’assurance qualité, les développeurs front-end et back-end. Dans ce cas, lorsque vous prenez des histoires du backlog uniquement sur la base de leurs story points, vous ne pouvez pas estimer correctement si certains des rôles seront surchargés de travail et d’autres pas assez. Par exemple, imaginez que l’équipe a pris 3 story et qu’elles comprennent toutes des tests très lourds mais que l’équipe n’a qu’un seul ingénieur QA. Vous pourriez dire que les story points devraient déjà inclure le travail de l’AQ. Oui, mais cela ne résout pas le problème car les développeurs vont effectuer le travail et la personne chargée de l’assurance qualité devra travailler dur pour tout supporter. Vous pouvez maintenant argumenter que les développeurs devraient sauter et soutenir avec des tests. Oui, bien sûr, ce serait le cas pour les équipes très performantes, mais que se passe-t-il si nous sommes dans la situation inverse, lorsque le service d’assurance qualité n’a pas assez de charge en fonction des histoires sélectionnées ? En général, l’assurance qualité ne peut pas se substituer au travail de développement. Et le problème est qu’habituellement, de tels cas ne deviennent visibles qu’après le début du sprint, et au milieu du sprint, l’équipe se rend compte que quelqu’un n’a pas de travail à faire.
C’est probablement l’une des raisons pour lesquelles le rapport State of DevOps montre que l’élimination des transferts au sein de l’équipe contribue à améliorer les performances de celle-ci. Pour notre exemple, cela signifie essentiellement que si vous n’avez pas d’AQ dans l’équipe, celle-ci sera plus performante.
La planification de la vélocité fonctionne généralement très bien pour les équipes expérimentées dont les membres n’ont pas changé depuis un certain temps et qui ont une bonne idée de ce qu’elles peuvent réaliser pendant le sprint. En revanche, elle ne fonctionne pas bien pour les équipes nouvellement formées, dont les membres changent souvent, ou dont le type de travail change également et pour lesquelles l’équipe doit apprendre à faire le travail.
Planification des capacités
Voici les étapes réalisées pour la planification des capacités :
- L’équipe calcule le total des heures disponibles par rôle. Par exemple, si l’équipe fait un sprint de 2 semaines, a 5 ingénieurs et un QA, alors le total des heures disponibles pour les développeurs sera de : 10 (jours ouvrables) x 8 (heures de travail dans une journée) x 5 = 400 heures et corrélativement 80 heures pour l’AQ.
- Appliquez le facteur de concentration au total des heures disponibles. Il est clair que personne ne peut être productif pendant les 8 heures de la journée, nous avons tous des réunions, des courriels à lire, et beaucoup d’autres distractions qui ne nous permettent pas de nous concentrer sur le travail pendant les 8 heures complètes. C’est pourquoi nous appliquons généralement un facteur de concentration, disons ~80%, ce qui signifie que nous serons productifs ~6 heures dans une journée de travail. Et donc la capacité totale disponible en heures sera égale à 300 heures de développement et 64 heures d’assurance qualité.
- Prenez une histoire dans le backlog du produit, décomposez-la en sous-tâches et donnez une estimation horaire à chaque tâche.
- Faites la somme des heures estimées de toutes les sous-tâches pour chaque rôle de l’équipe et comparez-les à la capacité du rôle pour déterminer si l’équipe a pris suffisamment de travail pour le sprint.
Ainsi, la planification de la capacité aide l’équipe à être plus précise dans la définition de la quantité de travail qu’elle prend pour le sprint et aussi à être capable de voir clairement s’il y a des rôles qui sont surchargés ou des rôles qui n’ont pas assez de travail. Cela permet aux équipes d’avoir les bonnes discussions, par exemple, que les développeurs prennent plus de travail de QA ou qu’ils apportent une autre histoire qui utilisera mieux les ressources de l’équipe.
L’inconvénient de la planification de la capacité est qu’elle nécessite beaucoup de calculs et de suivi au cours de la planification et, sans les bons outils, il sera vraiment difficile d’accomplir la bonne planification de la capacité avec moins de frais généraux.
La planification de la capacité fonctionne mieux pour les équipes nouvellement formées dont les membres changent souvent ou pour les équipes dont le carnet de commandes contient des travaux que l’équipe ne connaît pas. En général, les équipes expérimentées ignorent automatiquement la planification de la capacité lorsque les mêmes membres de l’équipe travaillent sur le même projet pendant une longue période ; ces équipes accordent généralement beaucoup plus d’attention à leur intuition pour comprendre la quantité de travail qu’elles doivent prendre.
Conclusion
La planification de la vélocité est lorsque l’équipe se base sur sa vélocité historique pour définir la quantité de travail qu’elle doit prendre dans le sprint actuel. La planification de la capacité est lorsque l’équipe projette la disponibilité future des membres de l’équipe, estime les tâches et prend la quantité de travail correspondante.
La planification de la vélocité fonctionne généralement très bien pour les équipes expérimentées dont les membres n’ont pas changé depuis un certain temps et qui ont une bonne idée de ce qu’elles peuvent accomplir pendant le sprint. La planification de la capacité fonctionne mieux pour les équipes nouvellement formées dont les membres changent souvent ou pour les équipes dont le backlog de produit comporte des travaux avec lesquels l’équipe n’est pas familière.
Dans mon prochain article, je décrirai une approche de planification qui combine ces deux approches et qui, pour moi, est la meilleure façon de diriger la réunion de planification selon moi. Il s’agit d’une approche qui a fait ses preuves dans mes propres équipes pendant de nombreuses années. Je vais également partager l’outil (modèle excel) que j’ai développé et qui permet de mener la réunion de planification de manière organisée qui m’a bien servi pour plusieurs projets.
