L’une des premières questions que l’on me pose (en dehors de quel outil digital doit-on utiliser), lorsque j’interviens dans l’accompagnement d’une nouvelle équipe qui souhaite mettre en oeuvre les pratiques agile, est comment vont se faire les estimations et la mesure de la capacité de l’équipe à tenir ses promesses.

Bien sur, une réponse facile serait de dire « on verra au fur et à mesure de l’avancement » ou alors « les estimations et les KPI ça ne sert à rien, faisons confiance à l’équipe ». Tout cela est bien gentil, mais la réalité est toute autre. Car, que l’on vienne du top management, du middle management ou de la team agile elle-même, ce sont des questions que l’on va se poser systématiquement lorsque l’on évolue dans un environnement loin d’être agile dans son mode de pensée (oui, ça existe encore), ou les budgets et les délais sont contraints, ou la notion de priorisation par la valeur est quelque chose d’abstrait et ou l’on va demander à un manager de donner une plus forte autonomie à l’équipe, sans lui apporter les éléments lui permettant de gérer ses activités de support, de suivi et de reporting (un manager qui n’a pas les bonnes informations ne peut pas jouer son rôle de facilitateur).

Dans cette série, je vous propose de présenter les différents type de KPI que j’utilise depuis quelques temps, auprès des équipes que j’accompagne.

Ce REX est découpé en trois partie. La première (cet article) portera sur les KPI Scrum, la seconde sur le passage de l’équipe vers un mode Kanban, avec la mise en place des KPI associés et la dernière décrira les indicateurs utilisés dans la mesure de la santé de la team agile, via la mesure de la maturité sur les pratiques (Scrum, Kanban), l’utilisation de pratiques du Management 3.0 (Moving Motivator) et du Health Check Maturity.

 Les principaux KPI Scrum

L’effort (Story point)

L’effort (on parle de Story point également) correspond au poids estimé d’une story (fonctionnelle ou technique). La mesure est réalisée par l’équipe de développement, lors du cérémonial Sprint Planning. Le total des efforts permet de définir le poids global du Product Backlog. Généralement, la suite de Fibonacci est utilisée pour effectuer la mesure de l’effort, via une séance de Planning Poker.

Attention, il ne s’agit pas d’une mesure en j/h, mais bien du sentiment de l’équipe de développement sur le niveau d’effort à fournir pour effectuer l’ensemble des étapes nécessaire à la réalisation de la Story (conception, coding, test, …). Donc, attention aux personnes qui auraient la sournoise idée de faire un ratio entre effort et j/h. C’est comme comparer des choux et des carottes, c’est juste idiot. Deux personnes réalisant chacune une Story de même effort ne vont pas obligatoirement le faire dans le même temps. Et je ne parle pas des cas ou la Story est réalisée en Pair-Programming.

La Prédictibilité (Capacité vs Vélocité)

La Capacité est l’engagement que l’équipe va prendre sur un Sprint. Elle correspond à la somme des efforts des Stories embarquées dans le Sprint.

La Vélocité correspond à la somme des efforts des stories « Done » à la fin du sprint, c’est à dire celles validées par le Product Owner.

La comparaison des deux mesures permet de définir le niveau de prédictibilité de la team agile, c’est à dire sa capacité à tenir ses engagements.

Vous verrez que la prédictibilité est toujours assez faible au premier sprint. Cela est normal et ne doit pas être une source de stress et de tension au niveau de l’équipe et surtout du management. Une nouvelle équipe, sur un nouveau produit ne peut pas être ultra performante dès le début. Elle doit se roder, apprendre à travailler ensemble, maitriser son environnement, appréhender le niveau de complexité de l’application. Par la suite la prédictibilité va progresser, et permettre de définir à quel moment l’équipe atteint son rythme de croisière et quelle sera sa capacité à faire. A partir de ces éléments, une projection de la date d’atterrissage devient possible en identifiant combien de points pourront être réalisés à la date de fin de Release.

Vélocité moyenne

La mesure de la vélocité moyenne d’une équipe, permet d’identifier à quel moment celle-ci atteint son rythme de croisière, c’est à dire la vélocité correspondant à sa capacité à faire.

La vélocité moyenne est ensuite utilisée pour définir la capacité de l’équipe, par sprint, et également pour effectuer une projection de la date d’atterrissage, par rapport au poids total des fonctionnalités restant à réaliser.

La vélocité moyenne est, comme son nom l’indique, mesurée en faisant le ratio entre la somme des vélocité et le nombre de sprint réalisé.

Estimer la taille du Product Backlog (poids moyen d’une Story)

Estimer le poids global du Product Backlog reste un exercice long et qui peut s’avérer risquer. En effet, il est complexe pour une équipe débutant sur un nouveau projet d’estimer l’ensemble des Stories sur leur simple description « En tant que … Je veux … Afin de … ». Bien souvent, le management peut également prendre cette première estimation comme inscrite dans le marbre et engagement de l’équipe, sans jamais accepter que celle-ci puisse évoluer.

L’estimation de l’effort à fournir sur chaque story va s’affiner avec l’expérience acquise par l’équipe et devenir de plus en plus précise. C’est pourquoi j’utilise, à chaque sprint, le KPI de mesure du poids moyen d’une Story.  Le calcul se fait par le rapport entre le nombre total de Stories « Done » et la vélocité cumulée sur les différents sprints.

Le poids moyen mesuré est ensuite multiplié au nombre total de stories restant à réaliser dans la backlog (et non déjà estimée), ce qui donne le poids total du Product Backlog, affiné à chaque sprint. Dans le cas de l’équipe que j’accompagne actuellement, le poids moyen est par exemple passé, en quatre Sprint, de 4 points à 2.66 points, ce qui a permis un ajustement régulier du nombre de fonctionnalités réalisables dans le délai restant et ainsi mieux prioriser notre Release 1.

Ratio des anomalies / Story

Un des éléments pouvant perturber l’engagement d’une équipe Scrum est ce que l’on appelle communément la « Dette technique » et plus particulièrement les anomalies qui vont être identifiées sur des Stories réputées « Done ». Les anomalies à corriger sont autant de potentielles fonctionnalités qui ne pourront être réalisées et donc de la valeur métier perdue.

Pour mesurer le niveau de qualité de la Dette Technique, je suis un KPI mesurant le nombre moyen d’anomalies générées par Story « Done ». Le calcul se fait par le rapport entre le nombre de Stories « Done » et le nombre d’anomalies identifiées. Plus le ratio est important, plus cela met en risque la capacité de l’équipe à tenir ses engagements et sa prédictibilité.

Attention, les anomalies sont bien celles identifiées sur les Stories qui ont été validées, à l’issue du Sprint et non sur celles identifiées et corrigées durant le sprint.

Mon outil de mesure des KPI Scrum

Pour effectuer les mesures des KPI Scrum, je n’utilise pas d’outils digital, tel Jira ou autre, mais simplement un fichier excel que j’ai configuré pour effectuer un suivi des KPI et des graphiques associés.

Voici une copie du tableau de suivi des KPI et de quelques graphiques qu’il produit.

Tableau de suivi des KPI Scrum

Product Burndown Chart (Graphique de suivi des réalisations et de projection du reste à faire)

Suivi de la vélocité