Après avoir préparé notre Sprint backlog, ainsi que notre capacité de Sprint, il est temps de de voir comment définir une charge de travail réaliste (autrement dit, comment obtenir un Remaining Work cohérent avec la capacité de notre équipe pour ce Sprint)

Cet objectif devient généralement le focus principal de l'équipe vers la moitié du Sprint Planning, lorsqu'il commence a y avoir suffisamment de travail prévu et que l'on identifie quelques potentiels "goulots d'étranglement" (Trop de travail prévu pour les développeurs Front, trop de travail pour un membre d'équipe en particulier, etc.)

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.

Retour d'expérience : Comment j'estime mes tâches avec Azure Boards

Tout d'abord, j'aimerai partager un avis personnel sur l'échelle que j'utilise pour faire mes estimations.

La première question que je me pose (et que je pose à mes co-équipiers) n'est pas tant "Combien de temps cette tâche doit prendre", mais plutôt "Avec combien de temps serait-on confiant / confortable de pouvoir réaliser cette tâche proprement". Avec le temps, j'ai constaté que la première formulation donnait souvent des estimations serrées, parfois avec des implémentations que je qualifierais de "quick and dirty". J'ai l'impression que les développeurs pensent que "plus l'estimation est courte, plus le product owner sera content" (Ce n'est évidemment et heureusement pas toujours le cas, mais j'ai pu le constater assez souvent). C'est pour cette raison que j'ai tendance à préférer la seconde formulation, en m'autorisant à challenger le développeur si nous avons des intérêts stratégiques à obtenir une ou plusieurs features assez rapidement. Par défaut, je préfère donc partir sur une estimation réaliste d'un travail propre. Cette approche est également alignée avec ma vision sur les sujets de planification / organisation : il est généralement plus simple de gérer son avance que son retard :)

Pour l'échelle d'estimation, initialement j'aimais beaucoup utiliser la suite de Fibonacci pour représenter le fait que plus une estimation est grosse, plus le degré d'incertitude augmente. Cependant j'ai découvert que cette méthode n'était pas forcément la plus répandue et pouvait amener à quelques incompréhension, du coup j'utilise maintenant une version plus simplifiée :

• 1 heure
• 2 heures
• Une demi-journée (3 heures)
• Une journée (6 heures)

Par défaut, je n'ai aucune tâche qui dure moins d'1 heure (parce qu'une tâche implique généralement le temps de compréhension, de développement, de test, déploiement et communication). Si la tâche est vraiment trop simple, elle peut peut-être être regroupée avec d'autres tâches, ou comptée comme une tâche de 0 heure (plus de détails ci-dessous)

Je trouve que 90% de nos estimations peuvent correspondre à l'une de ces 4 valeurs (en découpant ou en regroupant les tâches quand cela fait sens). Pour les 10% restants, j'utilise parfois la tâche de 0 heure (ou la tâche "gratuite) quand le sujet est vraiment trivial, ou encore du entre une demi-journée et 1 journée, ou du 1 journée et demi voire 2 jours pour les tâches les plus complexes telle que des sujets d'architectures ou PoC / Spikes. Mais encore une fois, ce sont des exceptions qui confirment l'échelle utilisée pour la plupart de mes estimations (Et il est important que ce ratio soit conservé).

Ce genre de discussion pourrait se poursuivre à l'infini, mais revenons plutôt à la configuration d'Azure Boards.

Choisir une stratégie de suivi pour le travail planifié ou non, ne concernant pas le développement

Pour chaque Sprint, on a généralement quelques charges de travail récurrentes. Il nous faut définir comment nous souhaitons les prendre en compte, en essayant si possible d'impacter le moins possible le suivi du bon déroulement des développements.

Par exemple :

1. Le Sprint Planning
2. La Démo de Sprint + sa préparation
3. Le rétrospective de Sprint
4. La relecture technique d'User Stories avant le début du Sprint Planning (Comme décrit dans le premier article de cette série)
5. La correction de Bugs (aouch. Celui-ci pourrait mériter son propre article de blog à part entière haha)
6. etc.

Pour les points 1 à 4, nous avons choisi quelques valeurs fixes : Une demi-journée pour le Sprint Planning, 2h pour la démo et entre 1 demi-journée et 1 journée pour la relecture technique. Pour chaque membre participant au meeting, je crée une tâche correspondante et la lui affecte durant le Sprint Planning.

Grâce à ces tâches récurrentes, les membres d'équipe peuvent prendre le temps de participer pleinement à ces réunions importantes, sans se soucier de mettre en danger le Sprint Burndown !

Vous pouvez importer toutes ces tâches récurrentes dans Azure DevOps d'un seul coup via Excel

Concernant le bug fixing, nous touchons ici à un sujet très largement et passionnément débattu (je vous laisse regarder estimating bugs sur votre moteur de recherche préféré).

J'ai assez apprécié quelques réponses fournies par Dan Makarov dans sont article How Should You Estimate Bugs?, et je vous invite à essayer plusieurs des méthodes décrites durant quelques Sprints pour voir si ce mode de fonctionnement pourrait convenir à votre équipe. Au final, tout est une question de curseur à régler entre être totalement à l'aveugle sur sur la correction de bug, et passer trop de temps/d'efforts à essayer de les estimer :)

Personnellement, je suis assez fan de la réservation de temps de correction sur chaque Sprint (entre une demi-journée à 1 journée par membre) pour permettre d'absorber la plupart du bug fixing.

Encore une fois, j'ai bien peur qu'il n'y ait pas de réponse universelle et que tout soit une question de préférence de fonctionnement/d'organisation dans votre équipe (N'hésitez pas à me contacter pour une discussion ouverte sur le sujet sur Twitter ou dans les commentaires)

Azure Boards - Obtenir une charge de travail réaliste pour un Sprint

C'est la dernière partie de cette série ! Si vous avez réussi à suivre jusqu'à maintenant, tout d'abord félicitations ! Il ne manque plus grande chose pour obtenir un joli départ pour votre Sprint !

Ce qu'il nous reste est très simple :

• Regarder la partie Work details du sprint courant, et s'assurer qu'aucune "barre rouge" ne soit présente, et tout ira bien !

Et pour ça, Azure Boards nous fournit 3 angles de vue différents pour s'assurer que le périmètre que l'équipe s'engage à délivrer soit le plus atteignable possible :

• Tout d'abord nous avons le Work: la capacité globale de votre équipe versus le Remaining Work déjà présent dans le Sprint.
• Ensuite, si vous avez pris le temps / fait l'effort de qualifier vos work items de type Tâche avec le champ Activity, ainsi que configurer les Activity de chaque membre d'équipe (depuis l'onglet capacity du Sprint), vous pourrez utiliser la métrique Work By: Activity : Avec cette vision, vous aurez plus de détails concernant un domaine particulier (C# et JS dans la capture d'écran par exemple) et détecter plus tôt si certains domaines ont déjà trop de travail de prévu, bien que la précédente métrique globale de Work semblait ok.

  Dans la capture d'écran en exemple, quelques développeurs full stack auraient besoin de s'occuper d'un peu plus de tâches JS, et pas uniquement de C# par exemple. Si vous n'avez pas de développeurs full stack, vous pourriez avoir envie de réduire le nombre d'US impliquant du travail côté JS

• Enfin, vous avez le Work By: Assigned To : en général, j'aimerais n'avoir jamais à utiliser cette métrique, car dans mon monde idéal, nous avons peu de tâches qui ne peuvent être prises en charge que par une unique personne de l'équipe, et les membres d'équipes peuvent décider au fur et à mesure quelles sont les tâches suivantes sur lesquelles ils seront les plus pertinents.
  Malheureusement, dans la réalité, c'est une chose qui peut arriver, et nous savons dès le départ quelle personne va traiter certaines tâches... Dans ce cas, nous les lui pré-affectons directement pour que, a minima, si trop de travail lui est affecté, sa "barre s'affichera en rouge". Cela nous permettra de décider soit de réduire le nombre de sujets l'impliquant, soit de réduire son temps de sommeil  :)

Cette partie work details est vraiment utile, et elle vous permettra également de savoir quand vous pouvez arrêter le Sprint Planning : Lorsqu'il y a suffisamment de Remaining Work revue pour remplir la barre de Work !

Et quand c'est le cas, c'est généralement le moment de souhaiter bonne chance à tout le monde, et commencer à focaliser sur la réalisation de ce nouveau Sprint !

Pour résumer

Ouf, c'est tout ce que j'aurai à dire sur ce sujet de Sprint Planning qui me semble crucial. J'espère que cet article vous aura permis de découvrir de nouvelles choses ou de confirmer vos propres pratiques (ou vous a passablement indigné, et vous souhaitez vous exprimer dans les commentaires ou sur Twitter @vivienfabing?)

Dans tous les cas, je vous souhaite bon courage, et que le code soit avec vous !