Le graphique de vélocité

Mesurer sa vélocité c'est une pratique agile recommandée.

C'est d'ailleurs une des demandes du test Nokia, une équipe doit connaître sa vélocité pour être considérée comme appliquant vraiment Scrum.

En plus du burndown chart, cela permet d'afficher un beau graphique qui montre l'évolution de la vélocité mesurée à chaque fin de sprint :

Graphe de vélocité simple

Si les éléments du backlog sont typés, par exemple en user story, technical story ou défaut, le graphique de vélocité enrichi permet de voir la contribution de chaque type d'élément à la vélocité :

Graphe de vélocité enrichi

Ce graphique permet de connaître, en plus de l'évolution de vélocité (voire de son accélération), la proportion de vélocité qui apporte directement de la valeur par rapport à celle qui contribue à rembourser la dette.

La production de ce graphique, c'est une user story de l'équipe IceScrum pour le sprint en cours. Il sera dans la version R2#11 du 6 février.

Commentaires

1. Le mardi 27 janvier 2009, 19:33 par dave

1) la disponibilité de l'équipe pdt l'itération est-elle bien constante ?


le graphe de vélocité ne le dit pas

2) que s'est-il passé à l'itération 3 pour qu'il y ait autant de bug a corriger ?
le graphe permet de s'en rendre compte, c'est pour ça qu'il est fait. L'équipe doit faire une analyse cause-effet à partir de cette observation et en tirer un plan d'actions. Si l'équipe n'y arrive, qu'elle fasse appel à un consultant !

merci

2. Le jeudi 29 janvier 2009, 13:32 par Carlo

L'inclusion des défauts dans le calcul de la vélocité ne donne pas une fausse idée de la capacité de l'équipe à produire de la valeur?

je crois plutôt qu'une idée fausse est de croire qu'un défaut n'a rien à voir avec la valeur (il la diminue), et qu'une autre idée fausse est de penser que la vélocité a un rapport avec la valeur (la vélocité est calculée avec des points relatifs à la taille d'un élément, ce qui n'a rien à voir avec sa valeur).

Dans mon équipe (en pleine transition à l'agilité) on a décidé de ne pas compter le temps passé sur les corrections de bugs relatifs à des stories marquées comme terminées dans une itération précédente.
Nous pensons que cela évite l'effet pervers de terminer des stories à l'arrache pour récolter les points de vélocité, tout en laissant glisser des bugs à la prochaine itération (ce qui va rapporter encore des points...)

Si terminé à l'arrache signifie pas vraiment fini, les conditions de satisfaction de la story ne seront pas toutes testées avec succès et la récolte sera de 0 point. C'est encore plus radical.

Y a-t-il des inconvénients à cette approche qui nous ont échappé?

Merci

3. Le mardi 03 février 2009, 16:03 par oaz

"récolter les points de vélocité"

Ce terme là a de quoi faire bondir. La vélocité n'est pas la productivité.

Bien d'accord avec toi Olivier. C'est même le titre d'un billet que j'ai écrit il y a quelque temps.