Cinq métriques de KPI Agile que vous ne détesterez pas
Les statistiques et les tableaux sont des outils puissants. Utilisez-les sans hésiter, chers agilistes. Sans hésiter.
Procurez-vous gratuitement le modèle de rapport de projet
Simplifiez votre processus de reporting grâce à des rapports cohérents et complets qui permettent d'établir une vue d'ensemble de vos projets.
Points clés
Les métriques Agile, comme le burndown de sprint, la vélocité, la durée de cycle et les diagrammes de flux cumulés, aident les équipes à suivre l'avancement et à optimiser la livraison.
Ces métriques offrent une meilleure visibilité sur les performances de l'équipe, les goulots d'étranglement et la capacité de prévision pour les prochains sprints.
L'examen régulier des métriques favorise l'amélioration continue et une prise de décision fondée sur les données.
Intégrez les métriques Agile dans les rétrospectives pour identifier les tendances et affiner le workflow de votre équipe afin d'obtenir de meilleurs résultats.
Les métriques 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 métriques une relation d'amour/haine.
Mais ce n'est pas une fatalité. Le suivi et le partage de métriques Agile 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.
What are Agile metrics?
Agile metrics are quantitative measures used to track the progress, quality, and effectiveness of agile teams and projects. Common metrics include velocity, lead time, cycle time, burndown charts, and cumulative flow diagrams.
These metrics help teams identify bottlenecks, forecast delivery, and drive continuous improvement. For example, tracking velocity allows teams to predict how much work they can complete in future sprints, while monitoring cycle time highlights areas for process optimization.
What is a KPI in Agile?
A KPI (Key Performance Indicator) in Agile is a specific metric used to measure the success of a team or project against defined goals. KPIs might include customer satisfaction, defect rates, or time to market, depending on what’s most important to the organization. Selecting the right KPIs ensures that teams stay focused on delivering value and achieving strategic objectives. For example, a team might track the number of critical bugs resolved per sprint as a KPI to improve product quality and customer experience.
Comment utiliser les métriques de KPI Agile pour optimiser votre livraison
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 indicateurs 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.
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.
Anti-schémas à surveiller
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.
Anti-schémas à surveiller
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.
Anti-schémas à surveiller
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.).
Anti-schémas à surveiller
À 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.
Anti-schémas à surveiller
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.
More Agile metrics
Good metrics aren't limited to the reports discussed above. For example, quality is an important metric for agile teams and there are a number of traditional metrics that can be applied to agile development:
How many defects are found:
during development?
after release to customers?
by people outside of the team?
How many defects are deferred to a future release?
How many customer support requests are coming in?
What is the percentage of automated test coverage?
Agile teams should also look at release frequency and delivery speed. At the end of each sprint, the team should release software out to production. How often is that actually happening? Are most release builds getting shipped? In the same vein, how long does it take for the team to release an emergency fix out to production? Is release easy for the team or does it require heroics?
Find insights in context
Insights are a great tool for teams to access metrics when they need them: during sprint planning, checking in at the daily standup, or optimizing delivery. You can find insights in the upper right-hand corner of the board, backlog, and deployments view of Jira.
Insights give a visual snapshot of the following metrics:
Sprint progress
Issue type breakdown
Sprint commitment
Deployment frequency
Cycle time
Use these metrics to continuously optimize team performance. Learn more about insights.
How do you measure the success of an Agile project?
The success of an Agile project is measured by evaluating both quantitative metrics and qualitative outcomes, such as delivering value to customers, meeting business goals, and fostering team collaboration. Key indicators include on-time delivery, stakeholder satisfaction, and the ability to adapt to change. Teams often use a combination of metrics like velocity, customer feedback, and business impact to assess performance. For example, a project that delivers a high-quality product on schedule and receives positive user feedback would be considered successful in an Agile context.
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.
Recommandé pour vous
Modèles
Modèles Jira prêts à l'emploi
Parcourez notre bibliothèque de modèles Jira personnalisés pour différents départements, équipes et workflows.
Guide produit
Une introduction complète à Jira
Suivez ce guide étape par étape pour découvrir les fonctionnalités essentielles et les bonnes pratiques qui vous permettront d'optimiser votre productivité.
Guide Git
Comprendre les bases de Git
Que vous soyez débutant ou expert, utilisez ce guide Git pour apprendre les bases grâce à des tutoriels et des conseils utiles.