Faut-il “chiffrer” les tâches techniques ? Comment ne pas fausser les indicateurs ?(vélocité, charts…)
Question posée via Scrum Life
Faut-il “chiffrer” les tâches techniques (en story points) ? Si oui, alors les points de la story sont comptés 2 fois et faussent les indicateurs (vélocité, charts…), non ? Quand faire les tâches techniques, durant le sprint planning ? Il ne risque pas un peu de déborder ?
Ne pas utiliser la même unité pour tâches techniques et backlog produit
Beaucoup d’équipes “chiffrent” les tâches techniques, mais pas avec la même unité que les éléments du backlog produit. En effet, les deux estimations ne servent pas à la même chose.
- L’estimation des éléments du backlog produit servent à faire des prévisions au long court, par exemples de releases et surtout au-delà du prochain Sprint. On utilise de préférence une unité volontairement abstraite qui permet de simplifier la gestion de projet (les points), qu’on concrétise via une mesure factuelle (la vélocité).
- L’estimation des tâches techniques sert à l’équipe de développement pour s’organiser au quotidien et détecter les points de blocage. On va là utiliser une unité concrète (Jours.Homme/Heures.Homme) qui permettra par exemple à l’équipe d’être confiante en Sprint Planning en se projetant sur le travail qui sera fait. Le but n’est cependant pas de rentrer dans une estimation détaillée à l’heure près, aussi une bonne manière de faire est de se forcer à choisir entre les valeurs suivantes : 0, demie-journée, 1 jour ou 2 jours — à plus de 2 jours, il faut découper la tâche technique. Une encore meilleure manière de faire est de simplement s’assurer que chaque tâche fait moins de 1 jour : tout en limitant les problèmes liés aux estimations, c’est aussi un excellent moyen d’aider l’équipe à détecter les points de blocage — chaque tâche faisant au maximum 1 jour, alors si un jour on déplace une tâche vers “en cours” alors le lendemain elle doit bouger vers “terminé” sinon il faut se poser des questions.
Ne surtout pas mélanger les deux unités !
Il est vraiment important de ne pas mélanger les deux unités. Quand on fait les tâches techniques, quand on “déroule” tout le travail à faire, il ne faut pas se projeter par rapport à l’estimation en points et se dire “oh là là on a estimé ça à 2, il faut qu’on ne passe pas trop de temps dessus” ou inversement “ah on est large, on a estimé ça à 8, c’est l’occasion de se faire plaisir”.
Il faut juste faire le travail bien, comme il faut. Pour l’équipe de développement, il vaut mieux oublier les points tant qu’on est dans le cadre du Sprint courant. À la fin du Sprint, on mesurera combien de points ont été faits et on mettra à jour la vélocité, sans biais.
Le Sprint Planning sert à définir les tâches techniques
Oui, a priori on fait les tâches techniques durant le Sprint Planning. C’est justement un des buts et livrables de cette réunion.
À nuancer tout de même :
- L’équipe peut avoir parfois besoin de faire le découpage des tâches techniques en amont du Sprint Planning, sur certains sujets compliqués, sur lesquels ils ne savent pas comment avancer. Par exemple, c’est le meilleur moyen pour l’équipe de déterminer si elle a besoin de faire une investigation technique en amont. Essayer de découper en tâches techniques peut être la première étape avant de partir sur un Spike.
- L’équipe n’a pas à faire l’intégralité du découpage en tâches techniques en Sprint Planning. Elle doit en faire suffisamment pour pouvoir démarrer le Sprint, et elle continuera au fil de l’eau.
- Une exception : lorsque l’équipe de développement a du mal à “s’engager” en Sprint Planning, ce qui est assez courant avec une équipe jeune, qui n’a pas encore l’habitude de travailler ensemble et sur ce produit. Faire le découpage en tâches techniques pour l’ensemble des éléments du backlog de Sprint peut alors aider l’équipe à démarrer sereinement le Sprint.
- Au final, c’est à l’équipe de développement de s’organiser au mieux pour réussir ses Sprints. Une approche possible pour faire de découpage en tâches techniques est la Design Review, une réunion où l’équipe échange sur l’architecture d’un élément du backlog et donc en définir les tâches techniques.
Pour aller plus loin
Utiliser les tâches techniques pour aider l’équipe à s’engager en Sprint Planning
Comment utiliser les estimations en point
Comment bien utiliser la vélocité
Le Burn-Down Chart
La Design Review
Les Spikes
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
Et pensez à souscrire à ma newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact. je vous invite à .
À bientôt 😊
