Compter les jours, ça peut servir

Une mesure simple pour montrer le budget consommé par rapport à l'avancement

Je trouve que c'est mal de mesurer en heures le temps passé sur chaque tâche du sprint, mais c'est bien de savoir combien de jours ont été passés par l'équipe sur un sprint. C'est bien plus facile à collecter et cela permet de répondre à des questions comme :

  • combien avons-nous consommé sur notre budget ?
  • combien allons nous consommer compte tenu de l'avancement ?

Prenons un exemple simple, avec un projet pour lequel on a prévu un budget équivalent à 250 homme-jours et qui a un backlog de 100 points qui doit être fini pour une date qui correspond à dérouler encore 5 sprints.

Si tout se passait de façon linéaire, chaque sprint consommerait 50 hj et avancerait de 20 points. A la fin du premier sprint, il resterait 200 hj de budget et 80 points à faire, du deuxième 150 hj et 60 points...

C'est l'idéal. Mais ça n'arrive jamais, la vélocité n'est pas toujours la même et les ressources peuvent varier. Alors il est utile de savoir si on avance comme prévu, si on dépense comme prévu et si l'avancement est corrélé à la dépense.

Pour la consommation, il faut faire une mesure des ressources utilisées pendant le sprint. Avec un sprint de 2 semaines et une équipe de 5 personnes, les ressources utilisées sont de 50 hj si tout le monde est à plein temps. Les vicissitudes font que des personnes ne sont pas toujours à plein temps, parce qu'elles travaillent sur d'autres projets, parce qu'elles ont été malades, parce qu'elles sont en formation, parce qu'elles sont en vacances. A la fin du sprint, on fait le compte des ressources effectivement consommées sur le projet.

D'un autre côté, dans une approche agile, l'avancement se montre en regardant les points qui restent à faire et en produisant un burndown chart. En ajoutant sur le graphique le reste à consommer des ressources, on obtient un schéma comme cet exemple :

Les valeurs sont celles relevées à la fin de chaque sprint. On voit que la consommation des ressources (rouge, avec l'échelle à droite) descend plus vite que la réalisation des éléments du backlog (bleu, avec l'échelle à gauche). Cela permet de se rendre compte tôt que le budget sera insuffisant pour tout faire.

Dans certains cas, une vélocité en baisse pourra être expliquée par une diminution des ressources pendant un sprint. Par exemple :

Il est possible d'enrichir le diagramme en tenant compte des changements de périmètre, des changements de ressources et en faisant figurer les estimations faites en début de sprint en plus des valeurs relevées à la fin de chaque sprint.