KPIs Game (2/3) : Les KPIs de prédictibilité

Retrouvez la première partie de cet article sur les KPIs d’équipe depuis ce lien : KPI Game (1/3) : les KPIs d’efficacité.
Cette deuxième partie aborde les KPIs de prédictibilité.

À suivre, KPI Game (3/3) : les KPIs de qualité.

Les KPIs de prédictibilité

Les KPIs présentaient ci-dessous permettent, notamment au PO, d’être plus fiable dans l'estimation du contenu du prochain sprint, de suivre le respect de la roadmap, etc.

La prédictibilité

Comment la calculer ? La prédictibilité se mesure en calculant le ratio entre la vélocité estimée en début de sprint et la vélocité réelle (celle des US done) en fin de sprint. Exemple : Une équipe ayant en fin de sprint réalisé 40 story points sur 50 story points embarqués en début de sprint aura un pourcentage de confiance de 80%.
Pourquoi la suivre ? Cet indicateur permet d’évaluer, lors du sprint planning, le taux de confiance vis-à-vis des estimations de l’équipe ou l’engagement en nombre d’US pris par l’équipe dans le sprint.

Comment l’analyser sur le temps ? Comme pour tous les KPIs, il faut suivre l’évolution dans le temps pour analyser l’évolution et en tirer des axes d’améliorations si besoin. Réaliser la moyenne du taux de prédictibilité sur vos X derniers sprints, vous permettra de mettre en évidence des axes d’amélioration. Un pourcentage qui tend vers 100% indique que les estimations sont fiables. Si ce pourcentage reste élevé, la vélocité peut alors être considérée comme fiable et le meilleur indicateur pour dimensionner le prochain sprint. À l’inverse, un pourcentage faible peut avoir de multiples causes : une mauvaise compréhension des US par l’équipe de développeurs, un mauvais découpage, la découverte de problèmes techniques, une mauvaise analyse des impacts/risques ou une mauvaise connaissance du produit par l’équipe.

US créées VS résolues

Comment le calculer ? Comme son nom l’indique, ce KPI permet d’évaluer le ratio entre le nombre d’US créées par le PO et le nombre d’US résolues par l’équipe de développement au cours du sprint.
Pourquoi le suivre ? Cet indicateur permet d’évaluer si l’équipe délivre plus rapidement que le cadrage des features ou bien si, au contraire, des sprints seront prêts à l’avance.

Comment l’analyser sur le temps ? Un ratio régulièrement inférieur à 1 indique que l’équipe termine plus d’US en un sprint que le nombre d’US qui rentrent dans le backlog. Il y a donc un risque d’avoir rapidement des sprints où l’équipe de développement n’aura plus d’US à traiter avant la fin du sprint. Un ratio régulièrement supérieur à 1 indique que le backlog s’enrichit plus rapidement que ce qui est livré en production, cela est une alerte pour détecter le problème : l’équipe est-elle sous-staffée ? Autres ?

Lors de la création d’un produit, ce taux est très souvent supérieur à 1 : le backlog se remplit avec de nombreuses features. À l’inverse, lorsqu’un produit devient mature ou entre en fin de vie, il est normal de voir ce taux devenir plus petit que 1. Dans l’absolu, ce taux doit avoisier les 1, ce qui est souvent signe d’une cadence trouvé par l’équipe.

Le cycle time

Comment le calculer ? Le cycle time mesure, en nombre de jours ou d’heures, le temps nécessaire pour qu’une tâche (US, bug, feature, autre selon le cas) passe d’un statut A à un statut B. Dans un exemple où nous mesurons le cycle time des US de TO DO à DONE :

1. Mesurer le cycle time de chaque US, c’est-à-dire le temps écoulé entre son arrivée dans la colonne TO DO à son arrivée dans la colonne DONE.

2.Faire la somme des cycle times de toutes les US (sur une période définie) et diviser par le nombre d’US concernées pour obtenir le cycle time moyen des US sur la période.

Pourquoi le suivre ? Le Cycle Time permet d’identifier la/les étape(s) qui prennent le plus de temps dans le cycle de développement du produit et d’établir un plan d’actions pour réduire les délais et livrer plus rapidement.

Comment l’analyser ? Tout simplement en comparant le cycle moyen réel et celui « attendu ». Reprenons le cas précédent où nous calculons le cycle time moyen d’une US entre TO DO et DONE : une US est censée rentrer en sprint planning à TO DO et être développée au cours du sprint donc être à DONE avant la fin du sprint. Dans le cas où un sprint dure 2 semaines, il faut a minima que le cycle time moyen des US soit inférieur à 2 semaines. Si votre cycle time n’est pas satisfaisant à l’échelle du sprint, vous pouvez mesurer le cycle time sur les différentes étapes du cycle. Ce type d’analyse peut vous permettre de réaliser, par exemple, que l’étape IN PROGRESS représente 80% du cycle time complet. Cela peut s’expliquer par un mauvais découpage des US. A l’inverse, si les tests fonctionnels prennent 50% d’un cycle time, cela peut être dû à un manque de ressources QA ou à des critères d’acceptation mal définis en amont, etc….

Le lead time

Comment le calculer ? Le Lead Time n’est ni plus ni moins que le Cycle Time sur un cycle « complet » : le Lead Time mesure en nombre de jours le temps nécessaire pour qu’une tâche (US, bug, feature, autres selon le cas) traverse toutes les étapes d’un workflow : de la demande initiale jusqu’à la mise en production.
Dans un exemple où nous mesurons le Lead Time des US :

1. Mesurer le lead time de chaque US, c’est-à-dire le temps écoulé entre sa création et sa mise en production.

2. Faire la somme des lead times de toutes les US et diviser par le nombre d’US concernées = Lead time moyen des US. Comme tous les KPIs, il faut suivre ce KPI sur une période assez longue pour avoir un calcul de lead time moyen pertinent puis le suivre pour voir si les actions mises en place permettent de le diminuer. Conseil : vous pouvez suivre le lead time moyen sur une courbe afin de visualiser facilement sa tendance.

Pourquoi le suivre ? Il est important de connaitre son Lead Time afin de l’améliorer, si besoin, pour fluidifier le processus complet et de livrer de la valeur au client le plus tôt possible. Cela aide aussi à donner de la visibilité. Nous avons déjà tous vécu l’arrivée d’un nouveau sujet « urgent » pour lequel on nous demande un macro chiffrage et une visibilité sur sa réalisation : le lead time peut vous aider à donner cette visibilité !

Comment l’analyser ?Le lead time permet d’identifier le délai d’un processus, si celui-ci semble trop long par rapport à l’attendu, il faut identifier les actions possibles pour optimiser le délai. Quelques questions à se poser :

- L’ensemble des étapes automatisables le sont-elles ?
- Les équipes sont-elles suffisament staffées ? Évitez-vous les bus factor ?
- Avez-vous des goulots d’étranglements ?
- etc

‍