La vélocité avec Scrum
La vélocité, pour une équipe Scrum, est un nombre de points réalisés lors d’un sprint (relire l’ebook de Kniberg). C’est une forme de productivité de l’équipe par tranche de temps (le sprint), généralement quelques semaines, suivie à la granularité des user stories. Une forme de productivité car elle est repose sur un référentiel d’estimations relatives, propre à l’équipe : les story points.
Le burndown de Scrum et les points
Il faut préciser que la vélocité est utilisée principalement pour piloter le contenu d’une version. A ce niveau de pilotage, nous n’avons pas besoin d’une grande précision. Lorsque l’équipe et sa vélocité est stable, elle peut également servir pour piloter un Sprint, mais cela vient dans un second temps.
On suit donc le nombre de petites fonctionnalités effectivement réalisées au cours d’un sprint, pondéré par leur effort. A l’échelle d’une version, la granularité, plus que l’estimation, est importante.
Imaginez maintenant que les fonctionnalités ont toutes la même granularité. Les différences d’estimation sont alors un paramètre de second ordre pour piloter la version, et de premier ordre certes pour s’engager sur un sprint.
La vélocité, dans ce cas, serait proche du nombre de fonctionnalités réalisées par unité de temps. C’est la définition d’un débit.
Bien sûr, l’hypothèse que toutes les fonctionnalités ont la même granularité est rarement vérifiée. C’est une hypothèse permettant de mieux comprendre le lien entre vélocité et débit. Les deux notions sont très proches si l’on suit des stories, bien que la vélocité soit plus évoluée.
Débit et granularité
La notion de débit est intéressante à plusieurs points de vue. Elle suit un nombre d’éléments traversant un système, donc utile pour un système kanban, dont un des principes est de justement limiter le nombre d’éléments dans le système.
Ensuite, elle simplifie le suivi d’une performance : il est plus facile de compter que d’estimer. Elle repose sur des données objectives et factuelles : le nombre d’éléments. Mais cela a un prix : avoir des éléments, parcourant le système, de même granularité.
Pour une équipe Scrum ne souhaitant pas faire des estimations, mêmes relatives, cela peut être suffisant. Et lorsque les stories ne sont pas de même granularité, il suffit de suivre le débit des différentes granularités : simple, moyen et complexe par exemple.
Il est donc plus question de granularité, lorsque l’on suit un flux, que d’estimations comme lorsque l’on suit la capacité.
Passer de la vélocité au débit
Pour passer du suivi de la vélocité au débit, il faut compter le nombre de stories plus que les points réalisés sur un Sprint.
Ok mais il n’y a plus de Sprint en Kanban… Alors, on fait quoi ?
Kanban et Scrum peuvent très bien cohabiter (lire quelques articles et vidéos ici pour s’en convaincre). Il est tout à fait possible d’avoir des Sprints donc. Cependant, lorsque l’on bascule en mode flux, la question va réellement se poser.
Travailler en flux ne veut pas dire travailler sans filet. Et pour cela, Kanban utilise beaucoup la notion de cadence pour les moments importants ou l’équipe s’engage : planification et livraison.
Le débit est calculé sur la cadence de livraison des éléments finis. Une équipe basculant à Kanban, peut conserver la notion de vélocité, avec une définition basée sur le nombre de stories et la cadence de livraison.
Comment représenter la vélocité en Kanban ?
Puisque le débit est le pendant de la vélocité en Kanban, on peut suivre les deux de la même manière, à base de burnup pour le quotidien et d’histogramme pour l’historique.
Débit Kanban, à suivre par un burnup
