Résumé : les métriques Agile donnent un aperçu de la productivité à travers les différentes étapes du cycle de vie de développement (SDLC). Elles permettent d'évaluer la qualité d'un produit et de suivre les performances de l'équipe.
Les indicateurs restent un sujet sensible.
D'un côté, nous avons tous participé à un projet où aucune donnée, quelle qu'elle soit, ne faisait l'objet d'un suivi quelconque. Il était difficile de savoir si l'équipe était dans les temps pour la livraison ou même si elle se perfectionnait avec le temps. D'un autre côté, beaucoup d'entre nous ont eu la malchance de travailler sur des projets où les statistiques étaient brandies comme des armes, pour dresser les équipes les unes contre les autres ou pour justifier l'obligation de travailler un week-end. Il n'est donc pas surprenant de constater que la plupart des équipes entretiennent avec les indicateurs une relation d'amour/haine.
Mais ce n'est pas une fatalité. Le suivi et le partage d'indicateurs agiles utiles peuvent dissiper la confusion et mettre en lumière les progrès (et les contretemps) de l'équipe tout au long du cycle de développement. Voici comment.
Connaître votre business
Le mot « Terminé » ne révèle que la moitié de l'histoire. Le tout est de développer le produit adéquat, au moment adéquat et pour le marché adéquat. Pour garder le cap tout au long du programme, il est nécessaire de collecter et d'analyser certaines données en cours de route. Dans n'importe quel programme Agile, les métriques métier et Agile doivent impérativement faire l'objet d'un suivi. Les métriques métier évaluent si la solution répond aux besoins du marché, tandis que les métriques Agile mesurent les aspects du processus de développement.
« Les métriques métier d'un programme doivent être ancrés dans sa feuille de route. »
Pour chaque initiative de la feuille de route, ajoutez plusieurs indicateurs clés de performances (KPI) correspondant aux objectifs du programme. De plus, prévoyez des critères de réussite pour chaque exigence produit ; par exemple, un taux d'adoption par les utilisateurs ou un pourcentage de code couvert par les tests automatisés. Ces critères de réussite serviront aux métriques Agile du programme. Plus l'équipe apprend, mieux elle peut s'adapter et évoluer.
Comment utiliser les métriques de KPI Agile pour optimiser votre livraison
burndown de sprint
Les équipes Scrum organisent le développement en sprints limités dans le temps. Au début du sprint, l'équipe prévoit la quantité de travail qu'elle sera capable de réaliser pendant celui-ci. Ensuite, un rapport d'avancement de sprint présente le suivi du travail réalisé tout au long du sprint. L'axe X représente le temps et l'axe Y montre la quantité de travail qu'il reste à réaliser et qui est mesurée soit en story points, soit en heures. L'objectif est de terminer tout le travail prévu avant la fin du sprint.
Une équipe qui honore régulièrement ses prévisions fait la meilleure des publicités pour Agile au sein de l'organisation. Mais que cela ne vous incite pas à trafiquer les chiffres en déclarant une tâche terminée avant qu'elle ne le soit réellement. Cela peut sembler positif à court terme, mais à long terme, cela ne fera qu'entraver l'apprentissage et l'amélioration.
- L'équipe termine chaque sprint très rapidement parce qu'elle s'engage à réaliser trop peu de travail.
- Sprint après sprint, l'équipe ne parvient pas à honorer ses prévisions parce qu'elle s'engage à réaliser trop de travail.
- La ligne d'avancement affiche des chutes soudaines plutôt qu'une progression graduelle parce que le travail n'a pas été divisé en tâches granulaires.
- Le Product Owner allonge ou modifie le cahier des charges en cours de sprint.
Burndown d'epic et burndown de version
Les graphiques d'avancement d'epic et de version montrent l'avancement du développement sur un corpus de travail plus long que le graphique d'avancement du sprint. Les équipes Scrum et Kanban s'en servent comme guide de développement. Dans la mesure où un sprint (pour les équipes Scrum) peut contenir des tâches issues de plusieurs epics et versions, il est important d'assurer à la fois le suivi des différents sprints et des epics et versions.
Une « dérive des objectifs » désigne l'introduction de nouvelles exigences dans un projet déjà défini. Par exemple, si l'équipe livre un nouveau site web pour l'entreprise, la dérive consistera à demander de nouvelles fonctionnalités alors que les exigences initiales ont déjà été ébauchées. Dans un sprint, l'acceptation d'une telle dérive des objectifs est une mauvaise pratique. En revanche, dans les epics et les versions, le changement du périmètre est une conséquence naturelle du développement Agile. Au fur et à mesure que l'équipe avance dans le projet, le Product Owner peut décider d'accepter ou de supprimer certaines tâches en fonction des enseignements tirés. Les graphiques Burndown d'epic et de version permettent de sensibiliser tout le monde au flux et reflux du travail au sein de l'epic ou de la version.
- Les prévisions d'epic et de version ne sont pas actualisées au fur et à mesure que l'équipe avance dans le travail.
- Aucun avancement n'est constaté sur une période de plusieurs itérations.
- Les objectifs connaissent des dérives chroniques qui peuvent être le signe que le responsable produit ne comprend pas parfaitement le problème que le corpus de travail tente de résoudre.
- Le cahier des charge s'allonge trop rapidement par rapport aux capacités d'absorption de l'équipe.
- L'équipe ne fournit pas de livraisons incrémentielles tout au long du développement d'une epic.
Vélocité
La vélocité désigne la quantité moyenne de travail qu'une équipe Scrum réalise pendant un sprint. Mesurée en story points ou en heures, elle est très utile pour les prévisions. Le responsable produit peut utiliser la vélocité pour prévoir à quelle vitesse l'équipe peut terminer le backlog. En effet, le rapport montre le suivi du travail prévu et achevé sur plusieurs itérations. Plus il y a d'itérations, plus les prévisions sont précises.
Imaginons que le Product Owner souhaite atteindre 500 story points dans le backlog. Nous savons que l'équipe de développement réalise généralement 50 story points par itération. Le Product Owner peut, de façon raisonnable, supposer que l'équipe aura besoin de 10 itérations (environ) pour terminer le travail requis.
Il est important de surveiller l'évolution de la vélocité dans le temps. Les nouvelles équipes peuvent s'attendre à une augmentation de cette vélocité au fur et à mesure de l'optimisation des relations et du processus de travail. Les équipes déjà en place peuvent surveiller leur vélocité afin de garantir l'homogénéité des performances dans le temps et vérifier si une modification particulière du processus a permis des améliorations ou non. Une baisse de la vélocité moyenne est généralement le signe qu'une partie du processus de développement de l'équipe est devenue inefficace et doit être abordée lors de la prochaine rétrospective.
Lorsque la vélocité est irrégulière sur une période prolongée, revoyez toujours les pratiques d'estimation de l'équipe. Lors de la rétrospective de l'équipe, posez les questions suivantes :
- Certains défis liés au développement ont-ils été ignorés au moment de l'estimation de ce travail ? Comment pouvons-nous mieux diviser le travail pour déceler certains de ces défis ?
- L'équipe subit-elle une pression extérieure du métier pour dépasser ses limites ? En conséquence, l'adhésion aux bonnes pratiques de développement en souffre-t-elle ?
- En tant qu'équipe, faisons-nous preuve d'excès de zèle dans les prévisions pour le sprint ?
La vélocité est unique pour chaque équipe. Si l'équipe A présente une vélocité de 50 et l'équipe B une vélocité de 75, cela ne signifie pas que l'équipe B a un débit plus élevé. Comme la culture d'estimation est unique pour chaque équipe, sa vélocité le sera aussi. Résistez à la tentation de comparer la vélocité de différentes équipes. Mesurez le niveau d'effort et le travail réalisé en fonction de l'interprétation spécifique des story points par chaque équipe.
Tableau de contrôle
Les graphiques de contrôle se focalisent sur la durée de cycle des tickets pris individuellement, à savoir la durée totale écoulée entre l'état « En cours » et l'état « Terminé ». Les équipes qui présentent des durées de cycle plus courtes auront tendance à avoir un débit plus élevé, alors que celles qui présentent des durées de cycle régulières sur plusieurs tickets seront plus prévisibles en ce qui concerne la livraison du travail. Si la durée de cycle constitue une métrique principale pour les équipes Kanban, les équipes Scrum peuvent également retirer certains avantages d'une durée de cycle optimisée.
La mesure du temps de cycle est une façon efficace et flexible d'améliorer les processus de l'équipe. En effet, les résultats des changements sont notables presque immédiatement. L'équipe peut alors les ajuster dans la foulée. L'objectif final est d'obtenir un temps de cycle court et régulier, indépendamment du type de tâche (nouvelles fonctionnalités, dette technique, etc.).
À première vue, les graphiques de contrôle peuvent sembler inconstants. Ne vous inquiétez pas si des données sont aberrantes. Cherchez à en déduire les tendances. Voici deux aspects à observer :
- Augmentation de la durée de cycle : une augmentation de la durée de cycle mine l'agilité durement gagnée de l'équipe. Lors de la rétrospective de l'équipe, prenez le temps d'analyser cette augmentation. Exception : si l'équipe a étendu sa définition de l'état « terminé », la durée de cycle s'allongera probablement aussi.
- Durée de cycle irrégulière : l'objectif est de parvenir à une durée de cycle régulière pour les tâches qui présentent des valeurs similaires en termes de story points. Passez en revue le graphique de contrôle afin de vérifier la cohérence des valeurs de story points. Si la durée de cycle est irrégulière sur les petites et les grandes valeurs de story points, consacrez du temps, lors de la rétrospective, à l'examen des mauvaises estimations et à l'amélioration des estimations ultérieures.
Diagramme de flux cumulé
Le diagramme de flux cumulatif devrait être (plus ou moins) fluide de gauche à droite. Les bulles ou les creux, quelle qu'en soit la couleur, montrent les insuffisances et les goulots d'étranglement. Si le diagramme en comporte, recherchez les façons de fluidifier les bandes de couleurs sur le diagramme.
- Les tickets bloquants créent d'importants goulots d'étranglement dans certaines parties du processus et un vide dans d'autres.
- Croissance non maîtrisée du backlog au fil du temps. En conséquence, les Product Owners ne terminent pas les tickets obsolètes, ni ceux dont la priorité est trop basse pour qu'ils soient traités.
Encore plus de métriques
Les bons indicateurs ne se limitent pas aux rapports décrits ci-dessus. Par exemple, la qualité est un indicateur important pour les équipes agiles. Et de nombreux indicateurs traditionnels peuvent être appliqués au développement agile.
- Nombre de défauts identifiés :
- pendant le développement ?
- après la livraison aux clients ?
- par des intervenants extérieurs à l'équipe ?
- Combien de défauts sont reportés à une version ultérieure ?
- Combien de demandes arrivent du support client ?
- Quel est le pourcentage de couverture des tests automatisés ?
Les équipes agiles doivent également se pencher sur la fréquence et la rapidité des livraisons. À la fin de chaque sprint, l'équipe doit livrer le logiciel en production. À quelle fréquence cela se produit-il ? La plupart des builds sont-ils livrés ? Dans la même veine, combien de temps faut-il à l'équipe pour livrer un correctif d'urgence à la production ? La livraison est-elle simple pour l'équipe ou nécessite-t-elle des efforts héroïques ?
Accédez aux analyses en contexte
Les analyses constituent un outil puissant : elles permettent aux équipes d'accéder à des métriques quand elles en ont besoin (durant la planification du sprint, lors du bilan effectué pendant le stand-up quotidien ou durant l'optimisation de la livraison). Vous les retrouverez en haut à droite de la vue du tableau, du backlog et des déploiements de Jira.
Les analyses fournissent un aperçu visuel des métriques suivantes :
- Avancement du sprint
- Répartition par type de ticket
- Engagement de sprint
- Fréquence de déploiement
- Durée du cycle
Utilisez ces métriques pour optimiser les performances de l'équipe en continu. En savoir plus sur les analyses.
Conclusion…
Les métriques de KPI Agile ne sont que l'une des composantes de la culture d'une équipe. Elles fournissent une perspective quantitative sur les performances de cette dernière et définissent des objectifs mesurables pour elle. Mais même si elles sont importantes, n'en faites pas une obsession. Il est tout aussi important d'écouter le feedback de l'équipe pendant les rétrospectives pour renforcer la confiance au sein du groupe, améliorer la qualité du produit et accélérer le développement tout au long du processus de livraison. Utilisez à la fois le feedback quantitatif et qualitatif pour favoriser le changement.
Related resources
