Calcul agile des capacités — Partie 1 sur 2

Capacité d'un agile L'équipe est une mesure importante qui devrait être utilisée pour informer l'équipe de la charge de travail qu'elle doit assumer pendant son cycle de travail. réunion de planification de sprint Pour le prochain sprint, si la capacité et la charge de travail sont déséquilibrées, les membres de l'équipe doivent en discuter avec le responsable produit afin de trouver un équilibre.

Je présenterai trois méthodes de calcul de capacité :

• Méthode 1: Il n'est pas nécessaire d'estimer ou de calculer la capacité. Il s'agit d'une méthode simplifiée et idéale.
• Méthode 2: La capacité est estimée (en nombre d'heures) à l'aide d'un petit nombre de paramètres. Il s'agit d'une méthode approximative mais rapide pour estimer la capacité d'une équipe agile pour un sprint.
• Méthode 3: La capacité est calculée avec précision (en heures) grâce à un ensemble de paramètres complet, extensible et personnalisable. Cette méthode permet de calculer avec exactitude la capacité d'une équipe agile pour un sprint. Les calculs sont effectués très rapidement à l'aide d'un modèle Excel.

Dans cette première partie d'une série de deux articles de blog, je présente les méthodes 1 et 2. Je présenterai la méthode 3 dans la suite.  Partie 2À la fin de la deuxième partie, je vous proposerai des recommandations sur la méthode que vous pourrez choisir en fonction de la situation spécifique de votre équipe agile.

Méthode 1 : Il n'est pas nécessaire d'estimer ou de calculer la capacité.

Considérons la méthode la plus simple (et quelque peu idéalisée) d'une équipe agile bien soudée : une équipe dont les membres ont travaillé ensemble en mode agile pendant plusieurs sprints et ont atteint une vélocité stable. Par exemple, une équipe agile a travaillé lors des quatre derniers sprints et a démontré une vélocité mesurée dans une fourchette étroite (à plus ou moins 10 %), par exemple : 19, 21, 20 et 19 points d'effort. Dans cet exemple, la vélocité moyenne de l'équipe (moyenne des quatre derniers sprints) est de (19 + 21 + 20 + 19) / 4 = 19.75 ≈ 20.

Si la même équipe (exactement les mêmes membres) prévoit de travailler ensemble lors du prochain sprint, et que le nombre de jours de travail disponibles pour ce sprint est identique à celui des derniers sprints, et qu'aucun membre de l'équipe ne devrait être retiré du projet pour un effort significatif, alors l'équipe agile, dans ce scénario idéal, peut confortablement planifier 20 points d'histoire de travail pour le prochain sprint.

Dans cette méthode, il n'est pas nécessaire d'estimer ou de calculer la capacité réelle de l'équipe pour le sprint à venir, car plusieurs hypothèses idéales sont supposées vérifiées, telles que :

• Une équipe agile bien soudée a atteint une vélocité stable ; et la vélocité moyenne mesurée au cours des quatre derniers sprints est un indicateur avancé de la vélocité estimée pour le sprint à venir.
• La même équipe soudée travaillera lors du prochain sprint ; c'est-à-dire que les mêmes membres continueront à y travailler.
• Le nombre de jours ouvrables disponibles lors du prochain sprint est très proche de celui des derniers sprints ; autrement dit, le prochain sprint ne comportera pas un nombre inhabituel de jours fériés, aucun membre de l'équipe ne devrait prendre de longues vacances personnelles et aucun membre de l'équipe ne devrait voir sa capacité réduite en raison d'autres tâches en dehors du travail lié au sprint.
• La plateforme technologique restera la même pour le prochain sprint (aucun changement par rapport au sprint précédent).
• Aucune nouvelle connaissance du domaine n'est requise de la part des membres de l'équipe pour le prochain sprint.

Méthode 2 : La capacité est estimée en nombre d'heures à l'aide d'un petit nombre de paramètres.

Cette méthode s'applique lorsqu'une ou plusieurs hypothèses justifiant la méthode 1 sont fausses ou, du moins, douteuses. Si une ou plusieurs des conditions suivantes sont remplies, la méthode 1 ne doit pas être utilisée :

• L'équipe agile n'est pas encore bien soudée ; elle a connu par le passé des variations de vélocité erratiques d'un sprint à l'autre.
• La composition de l'équipe agile est susceptible de changer pour le prochain sprint par rapport au sprint précédent ; cela modifiera certainement la dynamique et la productivité de l'équipe.
• La capacité de l'équipe pour le prochain sprint devrait être différente de celle du sprint précédent en raison des fêtes de fin d'année, des vacances d'été ou d'hiver, etc.
• Les membres de l'équipe devront travailler sur une plateforme technologique différente lors du prochain sprint.
• Un ou plusieurs membres de l'équipe doivent apprendre et appliquer de nouvelles connaissances du domaine pour le prochain sprint.

Dans ce type de situation, nous ne pouvons pas considérer la vélocité moyenne passée comme un indicateur avancé de la vélocité estimée pour le sprint à venir. Il est nécessaire d'estimer le nombre d'heures dont l'équipe disposera pour le travail opérationnel pendant ce sprint. Cette méthode utilise un modèle simplifié basé sur les données historiques de l'organisation concernant le temps de travail opérationnel typique sur une journée de huit heures (si ces données existent et sont disponibles). D'après ces données historiques, l'équipe peut consacrer entre 60 % et 80 % de la journée de huit heures au travail opérationnel. Le temps restant (entre 40 % et 20 %) est alloué aux courriels et appels téléphoniques généraux, aux réunions d'entreprise, ainsi qu'à la préparation et à la participation aux réunions quotidiennes. mêlée Réunions, etc. Ainsi, on estime que chaque membre d'une équipe à temps plein dispose de 4.8 à 6.4 heures par jour (soit 24 à 32 heures sur une semaine de travail de 40 heures) pour les tâches opérationnelles. Par exemple, une équipe agile de huit membres à temps plein travaillant par sprints de quatre semaines estime sa capacité à 768 heures (8 x 4 x 24, soit 60 % de tâches opérationnelles) ou à 1 024 heures (8 x 4 x 32, soit 80 % de tâches opérationnelles) pour la semaine à venir.

Il est important de noter qu'il ne s'agit que d'une estimation approximative de la capacité d'une équipe agile, car elle repose sur un seul paramètre : le pourcentage de temps disponible pour les tâches opérationnelles, généralement entre 60 % et 80 %, selon les données historiques de l'organisation. En l'absence de données historiques, certaines organisations utilisent une estimation approximative (par exemple 75 %) basée sur des observations empiriques ou sur leur propre intuition quant à ce pourcentage.

L'estimation de la capacité sert de guide à l'équipe agile quant à la charge de travail (récits utilisateurs ou fonctionnalités à implémenter et anomalies à corriger) pouvant être planifiée pour le sprint à venir. Par exemple, si la capacité de l'équipe est estimée à 800 heures, son temps de travail estimé devrait s'en approcher. L'équipe peut dépasser sa capacité, mais de 5 % maximum ; dans cet exemple, le temps de travail estimé ne devrait donc pas excéder 840 heures.

Une équipe agile doit désormais estimer le nombre d'heures de travail planifiées en fonction de son backlog de sprint priorisé. L'effort pour chaque user story et chaque defect doit être estimé en heures idéales (et non en heures écoulées). Cette estimation peut être réalisée au niveau de chaque user story ou de chaque defect, par l'équipe, en se basant sur sa connaissance collective du travail à effectuer. Alternativement, chaque user story et chaque defect peut être décomposé en tâches et tests ; chaque tâche et chaque test est alors estimé en heures idéales, et ces estimations sont ensuite cumulées pour obtenir une estimation de l'effort pour chaque user story ou destructeur, également en heures idéales.

La méthode 2 ne fournissant qu'une estimation de la capacité basée sur un seul ou un petit nombre de paramètres, il ne s'agit que d'une mesure approximative. Si vous devez estimer précisément la capacité de l'équipe en nombre d'heures à partir d'un ensemble complet de paramètres, vous devrez suivre la méthode 3. Cette méthode sera présentée dans le deuxième partie de cet article de blog en deux parties.