Série “Les indicateurs d’équipe” : la prédictibilité
Nous présentons dans cet article la notion de la prédiction d’une équipe, une information essentielle pour préparer une nouvelle Release et pour suivre un projet.
Pourquoi connaitre la prédictibilité de l’équipe ?
Nous avons 2 types de prédiction:
- Pour préparer une nouvelle Release ou un nouveau Sprint,
- Lorsque la Release ou le sprint est lancé.
Connaitre sa prédictibilité est essentielle, car cela permet de:
- Estimer le nombre moyen de stories qui seront développées,
- Maitriser le périmètre et planning,
- Etre proactif en cas de dérive,
- Remonter les risques et trouver des solutions,
- Inspirer confiance vis à vis du Métier.
“When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of science.” — Lord Kelvin, British physicist and member of the House of Lords, 1824–1907
La prédictibilité pour préparer une Release ou un sprint
La prédictibilité d’une itération est calculée avec ces 4 informations qui se basent sur l’historique de l’équipe.
Pour information, durant cet article, nous nous concentrerons uniquement sur le nombre de stories.
La durée de l’itération
Il s’agit de déterminer la durée de l’itération souhaitée. Une itération peut être la durée d’une Release ou d’un Sprint.
Le débit de l’équipe
Le but est de connaitre combien de stories ont pu être traitées par itération par l’équipe. Pour la Prédictibilité, nous ne prendrons que les stories prêtes à être livrées.
La capacité de l’équipe
Il s’agit de consulter les membres de l’équipe pour connaitre leurs congés/absence pendant la période de l’itération souhaitée.
Il s’agit bien d’une capacité théorique, aussi il n’est pas nécessaire d’aller dans la précision (exemple : calculer la capacité en nombre d’heures de travail).
Exemple : Une équipe constituée de 8 membres. Le lancement de la Release est prévu début mai et durera 6 semaines (donc 30 jours ouvrés). 3 membres seront absent, soit 5 jours au total.
Sa capacité sera donc de : (8 x 30–5) x 100 / (8 x 30) = 98%
Le ratio Bug/story
L’équipe récupère le ratio bug corrigés par itération/stories de ses itérations terminées. Cette donnée sera nécessaire pour définir le nombre de bugs théorique que l’équipe aurait à corriger pendant la durée de l’itération. Bien sûr, plus vous aurez d’historique, plus votre indicateur sera pertinent.
Le calcul de la prédiction
Il s’agit du nombre moyen de Userstories et de Technical Stories pendant la durée de l’itération souhaitée.
Nous vous proposons cette formule simplifiée qui vous permettra d’avoir un nombre moyen de stories pour votre prochaine itération. Comme le calcul se base sur des hypothèses, il sera à pondérer en proposant une fourchette qui sera définie par l’équipe.
“The wrong hypothesis is better than no hypothesis.” — Inconnu.
“Your hypothesis is not only not right; it is not even wrong.” — Wolfgang Pauli (Prix Nobel en Physique, 1945).
Le cas particulier des Tests de Non Régression ou des tests de bout en bout
Comme vous le savez, les tests de non régression (TNR) ou les tests de bout en bout ne sont pas représentés dans vos kanbans car ils ne sont pas rattachés à des Userstories ou des Technical Stories, et donc ne seront pas indiqués dans vos indicateurs. Si vous connaissez à peu près le temps que les testeurs de l’équipe devront consacrer, une proposition serait de déduire cette durée dans le calcul de la capacité de l’équipe.
Vous n’avez pas d’historique de la capacité/débit de votre équipe ?
Calculez la capacité à faire de votre équipe avec les contraintes suivantes dans un premier temps si vous n’avez pas d’indicateur.
Un réalisateur = 5 jours par semaine de capacité à faire
- 20% pour rituels et vie d’équipe
- X jours en fonction de ses congés
- 20% de capacité à faire globale pour l’équipe toutes les 3 semaines pour cause de support
La prédictibilité lorsqu’une Release ou un Sprint est lancé
Il s’agit, en cours d’itération, de:
- Estimer à quel moment les stories seront prêtes à être livrées,
- Anticiper et réduire les risques qui pourraient survenir,
- Informer les différents acteurs de l’avancée des travaux.
L’indicateur est constitué de 2 axes :
- Sur l’axe des abscisses : le temps,
- Sur l’axe des ordonnées : le nombre de stories (à savoir : les Userstories, Technical Stories et les Bugs).
Nous avons recensé 3 étapes essentielles pour cet indicateur :
- La Backlog,
- Développement terminé : ce qui est prêt à être testé,
- Test terminé : ce qui est prêt à être livré.
3 courbes indispensables :
- La prédiction haute de développements terminés,
- La prédiction moyenne de développements terminés,
- La prédiction basse de développements terminés.
A partir de ces courbes, nous pouvons prédire avec une fourchette haute et basse :
- Le nombre de stories en fin d’itération,
- La date à laquelle le nombre de stories souhaitées seraient développées.
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.
Mais, attention, il y a 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.
D’autre part, il sera important d’avoir des stories équilibrées, relativement de même taille. Ceci dépendra de l’expérience et de la maturité de l’équipe.
Si vous souhaitez avoir des prédictions plus précises, les simulations de Monte-Carlo pourraient peut-être vous aider !
Quelques exemples
Tout d’abord, une mise en situation :
La Squad “John Doo” a décidé de se réunir chaque lundi matin pour présenter la Prédiction de la version en cours. L’équipe est dans sa 5ème semaine de Release qui dure 8 semaines.
Nous voici en début de réunion.
Cas d’un kanban dont le statut des stories n’a pas été mis à jour régulièrement
Marc (Le Scrum Master) — “Bonjour, je vous présente le diagramme de prédictibilité. On remarque qu’il nous reste 3 semaines et que les courbes de prédictibilité montrent que nous n’atteindront pas les 25 stories !”
Jean (le Techlead) — “Tu es sûr ? Pour moi, ton graphe est faux ! Car nous avons beaucoup plus que 10 stories qui ont été développées. “
En regardant le Kanban dans JIRA, l’équipe a finalement constaté qu’il ne s’agissait pas d’un problème d’indicateur. En fait, les stories n’avaient pas toutes été déplacées dans le Kanban. L’équipe a décidé de mettre à jour les stories régulièrement dans JIRA.
Suite à cette mise à jour régulière, l’équipe a constaté que leur prédictibilité moyenne était finalement bonne.
Dans cet exemple, l’indicateur n’était pas exploitable. Sans discussion d’équipe, nous aurions pu imaginer que l’équipe n’aurait pas atteint son objectif.
Cas d’une équipe qui doit gérer un découpage de userstories et un bug
Abdallahi (Le TestLead) — “Bonjour, je vous présente le diagramme de prédictibilité. On remarque qu’il y a une augmentation du nombre de stories depuis quelques semaines. Cela impact notre prédictibilité car on voit que même la prédiction haute n’atteint pas le nombre de stories de la Release.”
Frédéric (Le Product Owner) — “Oui, nous avons découpé deux userstories en 3 Amigos, c’est pour cela que nous avons plus de stories. Il y a eu aussi un bug bloquant qui est arrivé vendredi dernier.”
L’équipe a remarqué que seul le bug de Production était bloquant, les autres pourraient être dépriorisés dans une prochaine Release, avec l’accord du Métier.
L’équipe a informé le Métier et le Product Manager de ce risque en présentant le board. Le Métier a effectivement constaté qu’il sera difficile de tenir le scope prévu en début de Release et a décidé réfléchir sur la dépriorisation de certaines fonctionnalités/bugs non essentiels qui seront à traiter dans une prochaine Release.
Les courbes indiquent que l’équipe risque de ne pas tenir son scope. Le fait d’en discuter a permis de remonter ce risque au Métier et au Product Manager.
Cas d’une équipe avec un nouveau besoin Métier en cours de Release
Iman (développeuse) — “Bonjour, je vous présente le diagramme de Prédictibilité de cette semaine. Je viens de découvrir un pic au niveau de la Backlog. C’est normal ? La semaine dernière, le diagramme montrait que l’on atteignait notre objectif … maintenant ce n’est plus le cas !”
Frédéric (Le Product Owner) — “On vient d’avoir un besoin urgent à traiter qui vient du Métier. Vous pensez que nous pourrions le traiter ?”
L’équipe a demandé au Product Owner de leur expliquer le sujet et s’il avait challengé le Métier quant à la valeur business du besoin et de son urgence. Elle va proposer au Métier de prendre en compte en priorité ce sujet pour la prochaine Release ou sinon de déprioriser des fonctionnalités prévues dans la Release mais qui ne sont pas encore développées
Si cela se produit fréquemment, l’équipe a décidé de se donner une marge de capacité/vélocité afin d’absorber toute nouvelle demande lors de futures Releases.
Les courbes permettent de présenter rapidement et simplement toute nouveauté survenue dans le kanban.
Cas d’une équipe qui pourrait délivrer en avance de phase
Frédéric (Le Product Owner) — “Bonjour, je vous présente le diagramme de Prédictibilité de cette semaine. On est super performant pendant cette Release.”
Jean (le Techlead) — “Oui, c’est ce que nous disions en daily. Je crois que nous avons amélioré notre débit depuis le début de la Release.”
L’équipe a décidé de ne pas livrer en avance, mais a indiqué au Métier qu’elle traitera une partie de sa dette technique si la prédictibilité est confirmée les prochaines semaines et s’ils ne rencontraient pas de nouveaux bugs.
Lors de leur Retro, l’équipe a aussi confirmé que l’amélioration du débit était due à la montée en compétence de développeurs (moins de formations, amélioration de la maturité de l’équipe) et ont mis à jour leur calcul de prédictibilité avec ce nouveau débit.
La Prédictibilité s’adapte à la variation du débit de l’équipe.
Cas d’une équipe avec une absence non prévue de membres
Marc (Le Scrum Master) — “Bonjour, je vous présente le diagramme de prédictibilité. Tout se passe bien, comme vous pouvez le voir … sauf que je viens d’apprendre que 2 développeurs sont en arrêt maladie pendant 2 semaines.”
Jean (le Techlead) — “Mince les pauvres, dis-leurs que nous pensons à eux … Cela veut dire que notre débit sera plus faible. On risque donc de ne pas tenir les objectifs.”
L’équipe a décidé de contacter le Métier et le Product Manager pour les informer du risque de ne pas tenir l’objectif et qu’ils les tiendront régulièrement au courant de l’avancée des travaux pour confirmer ou non ce risque.
D’autre part, en prévision de la confirmation de ce risque, le Métier a décidé de réfléchir sur les fonctionnalités qui pourraient être dépriorisées.
Les indicateurs seuls ne font pas tout. Une analyse de l’équipe est essentielle pour remonter les risques et pour trouver des solutions.
Cas d’un sujet qui a été annulé en cours de Release
Iman (développeuse) — “Nous sommes en semaine 8. Nous avons mis en Production la Release … Pourtant il reste des stories dans la Backlog. C’est normal ?”
Frédéric (Le Product Owner) — “Oui, ce sont les 5 stories de la MMF4 qui étaient prévues dans cette Release, mais le Métier a dépriorisé le sujet à la dernière minute. Elles sont annulées.”
L’indicateur a permis d’indiquer que l’équipe a pris du temps d’analyse d’un sujet, pendant cette Release, qui a — finalement — a été annulé.
En analysant le Lead Time, l’équipe a constaté un Cycle Time de Cadrage de 20 jours pour cette MMF4. Cela ne veut pas dire que l’équipe a travaillé pendant 20 jours sur la MMF, mais plutôt que, pendant cette durée, l’équipe a tout de même consacré du temps, à perte, pour analyser le sujet.
Les indicateurs aident à présenter, de façon factuelle, des dysfonctionnement.
Maintenant, c’est à vous de jouer en interprétant cette Prédictibilité …
… Qu’en pensez-vous ?
Pour consulter les autres épisodes de la série
Episode 2 : Série “les indicateurs d’équipe” : le débit | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
