Dans la méthodologie Scrum, il est de coutume d’estimer la charge de réalisation des tâches avec d’autres unités que le temps, notamment les points.
Le temps passe…
Pendant un sprint de 3 semaines (15 jours ouvrés), chaque membre de l’équipe travaillera 15 jours. Le temps ne fait que passer, il est incompressible et inextensible. Mesurer en temps n’est donc d’aucune utilité car si on prend cette mesure à la fin du sprint, on trouvera à nouveau 15 jours comme prévu au départ.
En plus, si on mesure le réalisé du sprint, on va se retrouver avec des choses incohérentes. Par exemple, si l’équipe a bien fonctionné, elle aura pu réaliser une tâche estimée à 20 jours en 15 jours de travail. A-t-elle ralenti le temps ?
Le temps n’est donc pas un indicateur de la performance de l’équipe Scrum.
L’abstraction
Estimer en temps paraît plus naturel pour tout le monde. Mais les membres de l’équipe n’ont pas tous la même expérience et les mêmes capacités donc pas la même productivité. Une unité abstraite va donc apporter un relativisme propre à l’équipe et, de fait, plus juste. Chaque équipe Scrum a son propre barème d’estimation qui découle directement de ses membres, de leur mentalité et de leur expérience commune. C’est un argument en faveur de la stabilité de l’équipe.
Sans m’étendre sur les techniques d’estimation, les abstractions utilisées habituellement dans Scrum offrent un autre avantage. Leurs échelles ne sont pas linéaires et permettent d’éviter les débats stériles sur une unité (ex. 2j, 2,5j ou 3j). La suite de Fibonacci est l’abstraction la plus connue. En général, j’utilise cet échantillon avec mes équipes : 0 – 1/2 – 1 – 3 – 5 – 8 – 13 – 20
La mesure
En fin de sprint, on additionne les points des stories terminées par l’équipe pour mesurer sa performance : c’est la vélocité.
Dans la théorie, cela paraît très simple. Dans la pratique, c’est un peu plus complexe surtout si votre workflow a été enrichi et comporte des états intermédiaires autres que TODO, IN PROGRESS et DONE. C’est là que le DOD prend toute son importance.
On remarque aussi des variations dans la vélocité en fonction du type de tâches réalisées d’un sprint à l’autre. De petites tâches simples en grand nombre, faciles à terminer, auront tendance à gonfler la vélocité. A l’inverse, des tâches plus complexes, difficiles à terminer, auront tendance à la faire chuter. Le niveau d’avancement des tâches joue aussi beaucoup sur ces variations. Durant un sprint, si l’équipe a avancé beaucoup de tâches mais terminé peu, sa vélocité sera faible. Dans le sprint suivant, si les tâches commencées sont poursuivies et terminées, la vélocité gonflera grâce au travail réalisé pendant le sprint précédent.
A cause de ces variations, la vélocité ne reflète pas toujours le vrai niveau de performance de l’équipe. Ainsi, j’ai pris l’habitude de relever d’autres indicateurs à mes équipes :
- « nombre de stories et total de story-points » embarqué au début du sprint (l’engagement)
- « nombre de stories et total de story-points » non-commencé laissé en TODO
- « nombre de stories et total de story-points » quasi-terminé (en test par exemple)
Cela permet de détailler le résultat du sprint et de relativiser la vélocité.
Relativiser les estimations
L’estimation de tâches est un exercice difficile et très incertain. Le mouvement « NoEstimate » le considère d’ailleurs comme un gaspillage de temps. De mon expérience, le travail d’estimation des tâches, réalisé lors du sprint-planning, a deux intérêts (dans l’ordre d’utilité) :
- permettre à l’équipe d’étudier les tâches, d’élaborer un plan pour les réaliser et d’obtenir un consensus sur ce plan
- améliorer la prédictibilité en se basant sur la performance connue de l’équipe mesurée par sa vélocité
A mon sens, la définition du plan et l’obtention du consensus de l’équipe sur ce plan justifient à eux-seuls le temps passé en estimations malgré leur faible fiabilité.
L’un des grands concepts des méthodes Agile est le découpage d’un gros travail en petits lots. En Scrum, on parle de sprints, en français, des itérations. Ce mode de fonctionnement présente de nombreux avantages mais demande une grande rigueur.