Beaucoup d’équipes Scrum fonctionnent avec un tableau de bord minimaliste: “à faire”, “en cours”, “terminé”. Le sprint avance, les items bougent de gauche à droite, et l’équipe découvre au Sprint Review que la moitié du backlog planifié n’a pas été livré. Le problème n’est pas Scrum en soi, c’est l’absence de données de flux pour piloter le travail en cours.
C’est précisément ce que Kanban apporte: non pas comme remplacement de Scrum, mais comme un ensemble d’outils de mesure qui rendent les événements Scrum plus efficaces. L’initiative Professional Scrum with Kanban de Scrum.org formalise cette intégration autour de quatre métriques clés.
Quatre indicateurs qui changent la conversation
Les métriques de flux issues de Kanban sont au nombre de quatre, et chacune éclaire un aspect différent du travail d’équipe.
Le WIP (Work In Progress, ou travail en cours) mesure le nombre d’éléments sur lesquels l’équipe travaille simultanément. Un WIP élevé est presque toujours synonyme de multitâche excessif: les membres de l’équipe jonglent entre plusieurs items, aucun n’avance vraiment et les goulots d’étranglement restent invisibles. Fixer une limite de WIP force une discipline simple: finir avant de commencer.
Le cycle time (temps de cycle) mesure le délai entre le moment où un item est pris en charge et sa livraison effective. Suivre cette métrique sur plusieurs sprints permet de détecter des tendances: si le cycle time augmente, quelque chose ralentit le flux, qu’il s’agisse de dépendances externes, de spécifications floues ou de dette technique accumulée.
Le throughput (débit) compte le nombre d’items livrés par unité de temps, typiquement par sprint. Contrairement aux story points, qui sont une estimation subjective, le throughput est un fait mesurable. Il offre une base plus fiable pour la prévision.
Le work item age (âge des items en cours) indique depuis combien de temps chaque élément actif est en cours de traitement. Un item dont l’âge dépasse le cycle time moyen de l’équipe signale un blocage qui mérite attention immédiate, et pas lors de la prochaine rétrospective.
Des données concrètes dans chaque événement Scrum
L’intérêt de ces métriques n’est pas d’ajouter des tableaux de bord supplémentaires, c’est de transformer la qualité des conversations dans les événements Scrum existants.
En Sprint Planning, le throughput historique remplace l’estimation intuitive. Plutôt que de se demander “combien de points pouvons-nous absorber?”, l’équipe consulte ses données: “au cours des cinq derniers sprints, nous avons livré en moyenne 12 items par sprint, avec une variabilité de plus ou moins 3.” La planification devient probabiliste plutôt que volontariste.
Au Daily Scrum, le work item age devient un signal d’alerte objectif. Quand un item dépasse son cycle time habituel, la question n’est plus “où en es-tu?” mais “qu’est-ce qui bloque cet item et comment l’équipe peut-elle le débloquer aujourd’hui?” La conversation se recentre sur le flux plutôt que sur le statut individuel.
En Sprint Retrospective, l’analyse du cycle time et du WIP sur la durée du sprint révèle des schémas récurrents. Une équipe qui observe que son cycle time explose systématiquement en milieu de sprint peut identifier une cause structurelle: trop d’items démarrés simultanément après le planning, créant un embouteillage que la limite de WIP aurait prévenu.
L’intégration délibérée, pas l’hybride de façade
Le risque principal de cette intégration est de la faire à moitié. Des équipes adoptent les limites de WIP parce qu’elles semblent raisonnables, mais abandonnent les rétrospectives parce qu’elles “prennent trop de temps”, ou conservent le sprint comme cadre temporel tout en supprimant le Sprint Review. Ce type d’hybride sélectif porte un nom dans la communauté agile: le “Scrumbut” (on fait Scrum, mais sans telle ou telle pratique). Le résultat est un cadre qui ne bénéficie ni de la rigueur de Scrum ni de la discipline de Kanban.
L’intégration réussie conserve l’intégralité du cadre Scrum (ses rôles, ses événements, ses artefacts) et y ajoute les pratiques Kanban comme une couche d’instrumentation. Les limites de WIP rendent les sprints plus fluides, les métriques de flux alimentent des décisions plus éclairées et le cadre Scrum fournit le rythme et la structure qui manquent souvent aux implémentations Kanban pures.
Commencer sans tout changer
L’adoption peut être progressive. Mesurer le cycle time et le throughput pendant trois ou quatre sprints sans changer les pratiques existantes donne déjà une base de données exploitable. Les limites de WIP peuvent être introduites ensuite, d’abord comme recommandation, puis comme règle d’équipe. L’essentiel est de commencer par mesurer avant de contraindre, pour que les contraintes soient fondées sur des observations réelles plutôt que sur des intuitions.
Pour les équipes qui ne sont pas dans le développement logiciel, cette approche est particulièrement pertinente. Un chef de projet dans le secteur public ou la construction qui utilise déjà des sprints ou des itérations peut intégrer ces métriques sans adopter l’outillage complet de l’agilité technique. Un tableur partagé qui suit le WIP et le cycle time suffit comme point de départ.