Série “les indicateurs d’équipe” : le débit
Nous présentons dans cet article le Débit, un indicateur essentiel pour mesurer le nombre moyen de cartes traité par période (jour, semaine, mois, itération …), au sein d’un kanban.
Le débit des cartes est une aide à la mesure de la prédictibilité d’un projet, à la condition d’arriver à avoir un niveau de granularité suffisamment fin entre les cartes ou au niveau de l’effort.
Comme vous le constaterez, nous y avons ajouté quelques exemples pour l’illustrer.
Le débit, qu’est-ce que c’est ?
Il s’agit d’un indicateur qui mesure l’écoulement de stories, de points d’effort, etc en fonction d’une unité de temps.
Durant cet article, nous nous concentrerons uniquement sur le nombre de stories.
Le débit d’un liquide et la loi de Little
Tout comme le débit d’un liquide, l’écoulement de stories dans notre Kanban suit exactement la même loi lors d’une Release ou d’un Sprint.
Il s’agit de la loi de Little. Cette loi, issue de la théorie des files d’attente, décrit la relation entre le temps d’attente, le stock, et le débit.
Dans cet exemple on constate que même si le débit est élevé dans les premières cuves, il existe un goulot d’étranglement au niveau de la cuve 3 qui régule le débit des autres cuves, même si elles ont une grande capacité. Le débit final dépend donc du débit de la cuve 3.
Nous vous proposons 2 exemples ci-dessous avec le même débit final (1 seule story qui sort), mais pour des raisons différentes. Comme vous pourrez le constater, il est important, dans l’analyse de cet indicateur, de mesurer toutes les étapes d’une story pour trouver le problème et les solutions adéquates.
1er cas : Un débit conditionné par la fin de chaine
Prenons l’exemple d’une squad constituée de:
- 1 Product Owner,
- 1 Business Analyst,
- 5 développeurs,
- 1 testeur.
On constate dans cet exemple que, malgré le nombre important de stories développées, le débit final de l’équipe dépend de ce que peut traiter l’équipe de test. Le goulot d’étranglement est à ce niveau.
2ème cas :Un débit conditionné par le milieu de chaine
Prenons l’exemple d’une squad constituée de:
- 1 Product Owner,
- 1 Business Analyst,
- 1 développeur,
- 3 testeurs.
Dans cet exemple, le débit final de l’équipe dépend du développement. On remarque aussi que l’équipe de test semble surdimensionnée par rapport à ce qu’elle doit traiter.
Comment est représenté le débit ?
Il est constitué de 2 axes :
- Sur l’axe des abscisses : le temps,
- Sur l’axe des ordonnées : le nombre de stories/unité de temps (à savoir : les Userstories, Technical Stories et les Bugs).
Nous avons recensé 3 étapes essentielles pour cet indicateur :
- Rédaction terminée : ce qui est prêt à être développé,
- Développement terminé : ce qui est prêt à être testé,
- Test terminé : ce qui est prêt à être livré.
C’est un indicateur propre à la Squad, il ne pourra donc pas être comparé à d’autres équipes car leur contexte, leurs maturité et leurs expériences sont différents.
Prenons l’exemple d’une squad qui consulte son Débit en semaine 5.
Quand consulter cet indicateur ?
La consultation peut se faire en 2 temps :
- Chaque semaine avec l’équipe : pour l’interpréter, remonter des risques et trouver des solutions. Cette analyse peut se faire conjointement avec le Cumulative Flow Diagram. De plus, lors de cette réunion, l’équipe peut se donner des objectifs pour la semaine qui vient de démarrer. Cela donne une notion de prédictibilité.
- A chaque préparation d’une prochaine Release pour définir la vélocité, la capacité de l’équipe pour s’engager sur un périmètre.
Des contraintes
Il est indispensable de responsabiliser chaque membre de l’équipe sur la mise à jour les stories dans votre outil Kanban (exemple: Jira). Leur statut doit être au plus près de la réalité pour avoir des indicateurs utilisables et fiables.
Pour interpréter de bons indicateurs, le kanban doit être à jour.
Autre contrainte, lorsque l’on choisit un débit par stories, vous le comprendrez bien, il est nécessaire d’avoir des stories de taille à peu près équivalente.
Quelques exemples
Tout d’abord, mettons-nous en situation
La Squad “John Doo” a décidé de se réunir chaque lundi matin pour présenter et analyser son débit de la semaine précédente.
Nous voici en début de réunion.
Cas d’un kanban avec des Userstories trop denses
Marc (Le Scrum Master) — “Bonjour, je viens de mettre en place notre indicateur sur le débit. Je voulais vous le présenter. Nous sommes en 5ème semaine de Release. Il s’agit bien uniquement des stories dont le statut a été mis à jour la semaine. Attention, il ne s’agit pas de l’ensemble des stories du kanban.”
Iman (développeuse) — “On remarque bien un problème sur ces courbes. c’est ce que nous indiquions depuis quelques jours en daily. Les Userstories sont trop grosses. Il y a trop de règles, si bien que l’on prend beaucoup trop de temps pour les développer. Par exemple, pour la première, qui était la plus simple, cela nous a déjà pris 2 semaines.”
L’équipe a décidé de revoir la taille des Userstories ensemble en mettant en place un 3 Amigos (Product Owner, Développeur, Testeur) pour les découper autrement et plus finement.
Le Product Owner a décidé de faire appel à la CoP Famille Produit pour que des Product Owners expérimentés puissent l’aider en faisant du Pair writting, à l’identique du Pair programming pour les développeurs.
Ce graphe montre qu’il y a un soucis au niveau du delivery des développeurs. Après discussion, l’équipe a mis en évidence que les userstories contiennent trop de règles à développer.
Cas d’une équipe sous-alimentée
Jacques (OPS) — “Bonjour, je vous présente l’indicateur débit. Cela fait un moment que l’on ne vous l’a pas présenté, mais on constate qu’il y a un goulot d’étranglement au niveau de la rédaction des stories, si bien que les développeurs et testeurs ne sont plus assez alimentés.”
Frédéric (Le Product Owner) — “J’en suis conscient. Cela fait 5 semaines que j’ai repris le poste de Product Owner et je ne maitrise pas encore le périmètre. Si bien que je mets pas mal de temps à écrire les userstories. En tous cas, merci à l’équipe pour m’avoir aidé depuis ces quelques semaines !”
Marc (Le Scrum Master) — “Dans tous les cas, nous avions informé le Métier que notre débit allait baisser du fait de ta montée en compétence.”
L’équipe a décidé de tester l’Event Modeling pour réduire l’impact sur les prochaines fonctionnalités (MMF) en faisant intervenir au plus tôt les développeurs, testeurs et OPS pour comprendre le sujet et préparer avec le Product Owner l’écriture des futures userstories.
On remarque par ce graphique l’impact sur le débit lorsque de nouveaux membres arrivent dans une équipe.
Cas d’un débit en Cycle en V
Abdallahi (Le TestLead) — “Bonjour, je vous présente le débit de la semaine dernière (semaine 9). Nous avons presque terminé les tests. Il reste quelques anomalies à corriger et des spec. à repréciser.”
Frédéric (Le Product Owner) — “Oui, j’en ai déjà corrigé une la semaine dernière.”
Jacques (OPS) — “Désolé, mais je ne vois pas trop l’intérêt de cet indicateur car tout a l’air séquencé … Je ne suis pas sûr que ce soit très agile.”
Après réflexion, l’équipe a demandé l’aide de la Communauté des Scrum Masters pour être accompagnés pour aligner leurs pratiques avec les autres équipes.
Cet exemple présente une équipe qui a décidé de faire du cycle en V (ou appelé aussi modèle Waterfall), à savoir qu’une étape doit attendre la fin de la précédente pour démarrer.
Cas d’une dépendance avec une autre équipe
Frédéric (Le Product Owner) — “Bonjour, je vous présente le débit de la semaine dernière. Le débit moyen de développement est de 3 stories. Or, cette semaine, nous avons un débit de 1 story. Vous savez pourquoi ?”
Jean (le Techlead) — “Oui, nous avons l’explication. Nous avions besoin du développement d’un contributeur sur la nouvelle API (Application Programming Interface). On l’a averti un peu tard. On a pris la userstory pensant que l’on recevrait bien les évolutions à temps. Finalement, on a bloqué la carte car il n’était pas dispo.”
L’équipe a décidé de remonter un risque sur l’appel de l’API en indiquant que la contribution avait été effectuée tardivement. Le contributeur finalement a indiqué qu’il serait disponible en semaine 6, ce qui a permis de fermer le risque.
Lors de la Retro de la Release, l’équipe a décidé d’ajouter ce contributeur :
- A leur prochain Event Modeling pour étudier les impacts fonctionnels et techniques avec lui,
- Aux prochains Release Planning, pour vérifier sa capacité et sa disponibilité si l’API était touchée lors de la future version.
En analysant le débit moyen par phase et en le comparant au débit de la semaine, cela a permis de remonter un évènement anormal.
Cas où le Product Owner mature une nouvelle Release
Marc (Le Scrum Master) — “Bonjour, Nous sommes en 7ème semaine de Release. Que peut-on expliquer de cet indicateur ?”
Frédéric (Le Product Owner) — “Concernant l’écriture des Userstories, j’ai terminé mes 15 Userstories de la Release. Je suis en train de travailler sur la maturation des prochaines fonctionnalités (MMF), pour la prochaine Release.”
Iman (développeuse) — “Bien sur, si nous allons plus vite que prévu, tu pourras nous alimenter ?”
Frédéric (Le Product Owner) — “Tout à fait, ou bien nous pourrions prendre des Technical Stories pour traiter la dette technique.”
Si le Product Owner prend beaucoup trop d’avance pour écrire ses userstories, le risque est que :
- Le besoin Métier change entre-temps,
- Ce qu’il aura écrit ne répondra plus aux attentes,
- Il aurait pu disposer de ce temps pour travailler sur des sujets plus prioritaires.
Ce graphe remonte le fait qu’il n’y a plus de stories écrite depuis quelques temps. Nous aurions pu penser qu’il y avait un problème, mais ce n’est pas le cas. Le Product Owner avait terminé d’écrire les userstories de la release.
Cas d’une indisponibilité technique
Jean (le Techlead) — “Bonjour, Nous sommes en 5ème semaine de Release. Comme indiqué en daily, nous avons eu un soucis technique la semaine dernière qui a ralenti nos développements, mais tout est revenu à la normale.”
Abdallahi (Le TestLead) — “C’est pareil pour les équipes de test.”
L’équipe a décidé de remonter un risque au Métier ainsi qu’au Product manager car, du fait de ce problème technique, l’équipe risque de ne pas tenir ses engagements. Le Product Owner a proposé de revoir avec le Métier les dernières userstories non développées qui pourraient être dépriorisées pour cette Release, si le risque était avéré.
Une chute de débit est un risque qui peut s’expliquer de différentes façons.
Cas d’une équipe qui se donne des objectifs pour la semaine
Marc (Le Scrum Master) — “Bonjour, nous sommes en semaine 6, je vous présente nos 2 diagrammes : le Cumulative Flow Diagram et le débit.
Pour le Cumulative flow, pour atteindre l’objectif de la Release (20 stories), il nous reste 13 stories encore à traiter (= 20–7 terminées) et 3 semaines avant la mise en Production.”
Jean (le Techlead) — “Si je comprends bien le graphe du débit, en moyenne, nous sommes à :
- 3 stories rédigées/semaine,
- 2 stories développées/semaine,
- 2 stories testées et terminées/semaine.
Si on se projette sur les 3 prochaines semaines, nous arriverions à (3 semaines * 2 stories terminées) = 6 nouvelles stories terminées.”
Abdallahi (Le TestLead) — “Mais, il nous reste 13 stories à faire ! Donc, en théorie, 7 stories ne pourraient pas être terminées pour cette Release ! En plus, on risque d’avoir des bugs à gérer.”
Marc (Le Scrum Master) — “Pour nous permettre d’avoir une prédictibilité, sur combien de stories vous pourriez vous engager cette semaine et avec quel indice de confiance ?”
Frédéric (Le Product Owner) — “De mon côté, j’aurai rédigé la dernière story demain et je pourrais donner un coup de main pour les tests dès cette semaine, si vous voulez.”
Les développeurs ont indiqué qu’1 userstory était presque terminée et qu’ils seraient capable de développer 4 autres stories cette semaine car ce sont des fonctionnalités maîtrisées. Donc l’indice de confiance est bon. Ce qui voudrait dire 5 stories développées en fin de semaine.
Les testeurs se sont engagés à tester 4 userstories cette semaine avec l’aide du Product Owner, avec un bon indice de confiance. Puis, ils essaieront de faire de même les semaines suivantes, mais avec indice de confiance est très faible.
D’autre part, l’équipe a décidé de continuer de définir ses objectifs chaque début de semaine (avec un indice de confiance).
En résumé : l’équipe prévoit de faire entre 16 et 20 stories pour cette Release.
L’équipe informera le Métier qu’elle pourra traiter pour cette Release 18 stories avec une marge de +/- 2 stories. D’autre part, ces chiffres leur seront reprécisés chaque semaine.
L’équipe a tout de suite rejeté l’idée d’ajouter de nouveaux développeurs et testeurs en urgence, car cela aurait eu l’effet inverse de celui souhaité. Le fait de passer du temps à les monter en compétence aurait réduit le débit de l’équipe au lieu de l’augmenter.
Ils ont aussi décidé de faire une Retro pour comprendre ce qui s’est passé et trouver des actions à mettre en place pour prévenir ce type de situation à l’avenir.
Maintenant, c’est à vous de jouer en interprétant ce débit …
… Mais, que se passe-t-il dans cette équipe ?
Pour consulter les autres épisodes de la série
Episode 3 : Série “Les indicateurs d’équipe” : la prédiction | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
