Vélocité d’équipe ou vélocité fonctionnelle

En Scrum, une équipe accepte la quantité de travail sur la base de sa vélocité passée. L’objectif est d’être raisonnable quant à la charge de travail à faire pendant le sprint. Selon les équipes, cette vélocité représente toutes les activités ou bien elle est seulement limitée aux activités fonctionnelles.

Prendre en compte toutes les activités

Une équipe agile mène plusieurs types d’activités : ajout de fonctionnalités (user stories), correction de fonctionnalités défaillantes (bugs), activités techniques (« technical stories ») ou correction de dette technique (refactoring). Tout cela est très bien résumé dans le schéma suivant défini par Philippe Krutchen, puis repris par Alex Boutin au Scrum Day 2015.

Analogie avec le bâtiment

En Agile, on se méfie souvent du domaine de la construction : planification en diagramme de Gant, analogie avec la maîtrise d’ouvrage et maîtrise d’oeuvre. On peut tout de même garder l’analogie car on y trouve aussi des imprévus, des corrections et changements de besoin. La dette technique existe aussi en peinture. Par exemple, lorsqu’on réalise un mélange de peinture au jugé, si on ne mesure pas précisément les quantités, on est incapable de reproduire exactement la même couleur.

Si l’on compare avec un chantier de peinture, la mise en place de l’infrastructure technique correspond à l’installation du chantier : bâches plastiques pour recouvrir le sol et les éléments inamovibles, retrait des éléments mobiles (caches prise, spot lumineux), … A l’inverse, le nettoyage du chantier avant livraison correspond à la dissolution de l’équipe avec l’archivage propre de l’infrastructure technique.

Comme en informatique, les corrections d’erreur (ici, les reprises de peinture) sont à la charge du prestataire.

Un Backlog représentant les activités de l’équipe

Lorsque le Product Backlog est exhaustif sur les activités de l’équipe, il contient des éléments des quatre types. Chacun est évalué selon la même échelle. Il appartient au Product Owner d’ordonnancer ces éléments en prenant en compte les intérêts de toutes les Parties Prenantes, y compris l’équipe agile.

Même s’il est fortement recommandé de maintenir un peu de fonctionnel à chaque sprint, la quantité peut varier fortement d’un sprint à l’autre en fonction des priorités des activités. Le diagramme ci-contre montre un fort besoin de refactoring dans le sprint 7 qui se fait au détriment du fonctionnel.

Limitation aux activités fonctionnelles

Malheureusement, cette vue reste bien souvent théorique. Pour les parties prenantes et leur représentant, le Product Owner, il s’agit de mesurer l’avancement du projet d’un point de vue fonctionnel. On peut alors introduire une autre vélocité : la vélocité fonctionnelle. Elle ne prend en compte que les activités de type fonctionnel. Elle correspond donc bien à l’avancement du développement fonctionnel du produit (ligne verte sur les diagrammes).

On peut alors « masqué » les travaux non-fonctionnels en consacrant un pourcentage constant de l’effort aux activités techniques et à la correction des défauts. La part des différentes activités dans cette marge impartie peut alors varier au gré des besoins. Et c’est l’équipe qui assure ce travail de priorisation sans l’avis du Product Owner, quand ce n’est pas le Scrum Master qui se prend pour un Product Owner des activités techniques ! Le diagramme ci-contre reproduit la même vélocité fonctionnelle que précédemment. Pour les activités non-fonctionnelles, la priorité est donnée à la correction des anomalies (même charge que précédemment), le tout rentrant dans un volume proportionnel à la vélocité fonctionnelle. On voit ainsi que la part de refactoring, jugée nécessaire dans le cas précédent, est fortement réduite.

Dans un tel cas, les activités non-fonctionnelles sont cachées : elles ne sont jamais démontrées.

Dans le cas d’un contrat de sous-traitance, on arrive même à avoir une vélocité contractuelle fixe. En théorie, avec le pourcentage fixe, la vélocité réelle est fixe. En pratique, on sait bien que, selon les difficultés, la vélocité de l’équipe varie un peu d’un sprint à l’autre.

Le second schéma reproduit la vélocité réelle initiale dans un contexte de vélocité fonctionnelle contractuelle fixe.

Cette solution cumule les inconvénients. En plus de l’arbitrage par l’équipe et de son opacité , on perd l’intérêt de la vélocité comme outil de monitoring pour l’équipe. L’équipe a tendance à boucler les éléments fonctionnels pour tenir le contrat. L’ajustement se fait donc sur la partie technique. Lorsqu’il y a besoin de refactoring (rachat de dette technique) et de mise en place d’outils technique (par exemple, renforcer le système de tests automatique), l’équipe privilégie le fonctionnel.

Visualiser le fonctionnel différemment

Une autre façon de suivre l’avancement fonctionnel consiste à utiliser un Cumulative Flow Chart dédié à l’ajout de fonctionnalités.

Ce diagramme donne visuellement une très bonne représentation  de la part prise par les différentes activités au cours du temps et pour le projet.

Recommandations

On a donc tout intérêt à considérer l’ensemble des travaux effectués, d’en conserver la maîtrise par le Product Owner. S’il n’y comprend pas grand-chose, le Scrum Master est là pour lui faire comprendre l’importance de ces travaux pour l’équipe.