Après avoir préparé au mieux notre Sprint Planning pour le garder court et efficace, voyons voir ensemble comment obtenir une capacité de Sprint réaliste pour notre équipe.

Disclaimer: Ces articles sont issus d'une opinion très personnelle sur laquelle vous avez le droit de ne pas être d'accord (c'est même vivement recommandé !). J'espère seulement que ce partage d'expérience pourra vous permettre de prendre vos propres décisions.

Préparation de la capacité du Sprint

Pour calculer la capacité du Sprint, Azure Boards va principalement compter le nombre de jours de travail dans le Sprint, et ensuite multiplier ce nombre par la capacité journalière exprimée en heures des membres de l'équipe.

Commençons d'abord par configurer les jours de travail d'un Sprint.

Configurer les jours de travail d'un Sprint`

Tout d'abord, nous pouvons paramétrer les Jours de travail de l'équipe si ce n'est pas déjà fait. (Notez que par défaut, seulement Samedi et Dimanche ne sont pas considérés comme des jours de travail).

Ensuite sans surprise, nous avons besoin de définir les dates du Sprint.

Puis finalement, nous devons nous assurer que tous les membres de l'équipes sont bien présents dans l'onglet Sprint capacity, et définir les jours non travaillés de l'équipe sur ce Sprint s'il y en a.

À partir de là, nous devrions déjà pouvoir vérifier le nombre de jours travaillés, calculés par Azure DevOps

Si pertinent, ne pas oublier de préciser également les jours off des membres de l'équipe.

Parfait, jusqu'à présent nous avons manipulé des jours, mais la plupart des fonctionnalités d'Azure Boards utilisent les heures, donc prenons le temps de convertir nos jours en heures

Retour d'expérience : Utiliser 1 jour = 6 heures pour convertir vos estimations

Étant donné qu'Azure DevOps se base sur des heures pour ses estimations, nous utilisons régulièrement la conversion 6 heures pour 1 jour ainsi que 3h pour 1/2 journée de travail.

La valeur de 1 jour correspondant à 6 heures est totalement arbitraire et fut choisie comme valeur qui nous semblait la plus pertinente, car elle nous permet d'avoir des estimations pertinentes, tout en évitant de micro traquer chaque tâche non anticipée (telles que les sessions de pair programming, les revues de code, les questions, les discussions, etc.)

Définition de la capacité globale du Sprint, ainsi que la capacité par membre et par activité

Étant donné l'échelle d'estimation donnée précédemment, nous pouvons configurer la capacité des membres de l'équipe, en précisant 6 heures pour une journée complète de travail par membre de l'équipe.

Avec ça, nous devrions déjà pouvoir voir la capacité globale du Sprint ainsi que la capacité individuelle de chaque membre de l'équipe depuis l'onglet Work details :

Dans l'image plus haut, la capacité globale de l'équipe est de 600 heures (équivalent à un Sprint de 10 jours pour 10 personnes par exemple), et 12 heures de travail à faire (Remaining Work) sont déjà présents dans le Sprint. Pour le membre d'équipe Vivien, sa capacité de travail est de 60 heures sur ce Sprint, et il lui a déjà été affecté 12 heures de travail.

Cette vue peut-être généralement constatée avant ou en début de Sprint Planning

C'est un bon début, et cela pourrait déjà être suffisant suivant votre contexte, mais je me suis retrouvé régulièrement à utiliser une autre fonctionnalité : Le champ Activity des Tâches.

Ce champ nous permet de catégoriser les Tâches par affinité : par exemple, j'ai déjà vu des équipes composées de développeurs JavaScript/TypeScript et de développeurs C#. Donc plutôt que de se cantonner à la vision de 600 heures de travail global pour l'équipe, pourquoi ne pas essayer d'obtenir une vision plus affinée du genre 180 heures de capacité pour du JavaScript/TypeScript, 300 heures de capacité pour du C# et 120h de capacité pour de l'organisation ?

À noter que par défaut, le champ Activity ne contient que les valeurs Deployment, Design, Development, Documentation, Requirements et Testing. Si vous souhaitez personnaliser ces valeurs, vous aurez besoin de customiser le champ Activity.
Si vous n'avez pas accès à la customisation des Work Items, vous pouvez toujours définir au sein de l'équipe une convention du genre Design pour les développeurs JavaScript, Development pour les développeurs C#, et Requirement pour les membres de l'équipe qui s'occupent de l'organisation globale, etc.

Pour cela, vous aurez besoin de revenir une fois de plus sur l'onglet Sprint Capacity et configurer cette fois-ci les Activity de chaque membre d'équipe (avec la possibilité d'en définir plusieurs pour un même membre d'équipe si celui-ci est amené à effectuer différentes types de tâches durant le Sprint)

Pour résumer

C'est tout pour cette seconde partie à propos de la capacité du Sprint avec Azure Boards.

J'espère que cet article aura pu vous donner une vision d'ensemble de la gestion de la capacité avec Azure DevOps. Évidemment, cet article est fortement lié au prochain article qui abordera le sujet d'obtenir un périmètre de travail réaliste pour un Sprint. (J'essaierai de rédiger ce prochain article sous peu pour ne pas laisser retomber le suspens haha)

N'hésitez pas à montrer votre désaccord ou toute autre opinion dans les commentaires ou par message via Twitter @vivienfabing.

Que le code soit avec vous !