Chiffrage du sprint par l'équipe Scrum au cours de la réunion de planning

Le chiffrage des tâches à réaliser par l'équipe est souvent un moment difficile, surtout si celle-ci est peu habituée à cet exercice.
Il n'est pas question ici de donner de solutions toutes faites pour faire ce chiffrage (qui dépend principalement de l'expérience de l'équipe), mais plutôt de nous attarder sur une question qui revient souvent lors des réunions de planning.

Quel doit être l’unité que doivent utiliser les développeurs pour effectuer leurs chiffrages ? 

La réunion de planning

Pour débuter chaque sprint, toute l'équipe se réunit avec le Product Owner pour définir le contenu du sprint à venir. Au cours de cette réunion, le Product Owner doit expliquer aux développeurs les user stories qu'il souhaite voir réalisées lors du prochain sprint. C'est à partir de là que le travail de l'équipe commence. L'équipe doit prendre un engagement sur les réalisations qu'il est possible d'embarquer dans le sprint, car en Scrum c'est bien l'équipe qui s'engage. On en arrive donc à notre problème, qui est que pour savoir combien de user stories on peut prendre dans le sprint, il faut bien les chiffrer.

Le chiffrage

Pour effectuer le chiffrage, une bonne pratique est de découper les user stories en tâches techniques suffisamment petites pour qu'elles soient réalisées en moins d'une journée de travail. Ceci permet de beaucoup simplifier le travail de suivi du sprint par la suite en évitant d'avoir à faire des réévaluations des tâches lors des Scrum meeting.

Ceci étant dit, il apparaît que l’unité de mesure qui semble la mieux adaptée est : l'heure de travail. Mais doit-on pour autant demander à l'équipe de raisonner en heures pour faire son chiffrage ?

Ma réponse est : ça dépend.

Ok avec une réponse comme celle-là on n’avance pas beaucoup, je vais donc me justifier.

Pour pouvoir faire son chiffrage, le développeur se base sur son expérience. De façon naturelle, cette expérience est construite sur la base d'un rythme facilement identifiable et intégré dans son schéma de pensée. Donc, sauf si le développeur en question prend le temps depuis des années de noter toutes les heures le travail réellement réalisé, l'heure n'est pas vraiment un rythme naturel. Par contre nos journées de travail sont (en général) bien rythmées sur le modèle suivant : j'arrive le matin - je travaille - je fais une pause déjeuner - je travaille - je rentre chez moi (ou je vais boire un coup avec les collègues). Le rythme naturel semble donc bien être la demi-journée. Cela veut dire que par son expérience un développeur doit avoir une bonne idée de ce qu'il est capable de faire dans une demi-journée.

Il n'y a donc plus de questions à se poser, il faut chiffrer en demi-journées. Non, pour certaines tâches très courtes (de l'ordre de 1 à 2 heures) l'esprit humain va raisonner en absolu, c'est à dire en heures.

Par exemple, si une des tâches correspond à modifier les libellés trop grands d'un écran pour éviter des retours à la ligne disgracieux. Un développeur ne va pas dire naturellement "il me faut 1/5eme de journée pour faire le travail", il va plutôt raisonner en heure et donner 1h30.

Il existe bien 2 façons de raisonner, et donc 2 unités de mesure pour qu'un développeur puisse faire ses évaluations, les jours et les heures. Il est donc nécessaire de définir une formule de conversion d'une unité à l'autre de façon à pouvoir faire un chiffrage du sprint entier dans la même unité. La 1^ere qui vient à l'esprit est de simplement convertir les jours en heures sur la base standard de 8 heures de travail par jours.

1ére Proposition de formule de conversion nb d’heures = nb de jours x 8

Mais cette approche souffre d’un problème, pourquoi 8 heures ? En effet un développeur ne passe pas tout son temps à programmer, il lit ses mails, fait des pauses café, discute de son week-end avec ses collègues, …

On appelle ce rapport entre le temps de présence et le temps réellement passé à produire du code, le facteur de focalisation. Il est généralement admis que ce facteur est de l’ordre de 70-75%, ce qui fait que sur une journée de 8 heures, le travail effectif est de l’ordre de 6 heures. Il semble donc naturel de dire que notre formule de conversion est :

2éme proposition de formule de conversion nb d’heures = nb de jours x 6

Ce n’est malheureusement toujours pas juste. Lorsqu’un développeur effectue un chiffrage en jours, la perception qu’il a de sa capacité de production basée sur son rythme de demi-journée prend automatiquement en compte ses temps de pause. Il intègre dans son référentiel le facteur de focalisation, il faut donc faire attention de ne pas le compter en double lors de la conversion.

Ce que je propose aux équipes que j’accompagne, c’est :

1. d’utiliser les heures comme unité de chiffrage,
2. de prendre arbitrairement le taux de conversion de 1 journée = 8 heures. C’est ce taux de conversion qui sera utilisé pour calculer la charge de travail disponible pour le sprint.
3. Lorsque le chiffrage est fait en heures, on lui ajoute le facteur de focalisation.

La bonne formule de conversion Soit : Eval = nombre d’heures à compter dans le sprint jdev = nombre de jours évalué par le développeur hdev = nombre de jours évalué par le développeur FFoc = Facteur de focalisation Eval = jdev x 8 + hdev (2 - FFoc)

 

 

Exemple d’application

Dans cet exemple nous prendrons le cas d’une réunion de planning pour une équipe de 3 développeurs qui travaillent avec des sprints de 2 semaines. Le facteur de focalisation de l’équipe est de 70%.

La charge de travail disponible

La charge de travail disponible sur le sprint est donc calculée sur la base arbitraire de 1 jour = 8 heures.

Charge de travail = 8 x jours par sprint x nombre de développeurs Charge de travail disponible = 8 x 10 x 3 = 240 heures

les évaluations

Lors de la réunion de planning, les 5 premières tâches sont évaluées par les développeurs de la façon suivante :

User Story	Tâches	Evaluation des développeurs	Evaluation retenue pour le sprint
User story 1	Tâche 1	0,5 jour	4 heures
User story 1	Tâche 2	0,75 jour	6 heures
User story 1	Tâche 3	1 heure	1,5 heure
User story 2	Tâche 4	3 heures	4 heures
User story 2	Tâche 5	0,5 jour	4 heures
		TOTAL :	19,5 heures

Il reste 220,5 heures de disponibles dans le sprint.

En conclusion

tout cela peut sembler un peu compliqué pour faire nos chiffrage. Je vous rassure, dans la vrai vie, nous sommes pas obligé de faire tous les calculs de façon très précise. Les choses importantes à retenir sont uniquement les points suivants :

• Dans un processus de chiffrage il existe 2 façons de raisonner
• En jours, en se basant sur notre rythme de journée.
• En heure, de façon absolue pour les petites tâches.   
• Quand on chiffre en jours, les temps d'improductivité sont pris en compte. Il ne sert à rien d'en rajouter
• Quand on chiffre en heures, les temps d'improductivité ne sont pas pris en compte. Il faut donc les ajouter (ou sur chiffrer un peu ces tâches).