Burndown de disponibilité au cours d’un sprint

[tplet]

Bonjour,

Je m’interroge sur le fonctionnement de la courbe de « reste à faire » qui tient compte de la disponibilité de l’équipe dans un sprint.

Pour un sprint de 2 semaines du lundi au vendredi, j’ai configuré la disponibilité de l’équipe à 7h par jour (disons une équipe de 2 personnes, soit un total de 10j x 7h x 2 = 140h de disponibilités au total).
Lorsque j’affiche le burndown de disponibilité, 2 courbes s’affichent : la réel, mise à jour chaque jour par l’équipe qui représente l’avancement, et l’idéal qui trace une courbe décroissante jusqu’à la fin du sprint (le reste à faire donc).

Cependant, je constate que cette courbe ne finit par à 0 le dernier jour mais à 14h.
Est-ce que la courbe représente le reste à faire au début de la journée ?

Dans nos pratiques (mais elles ne sont peut-être pas correcte), nous utilisons la courbe idéale comme une cible de fin de journée. En toute logique, à la fin du sprint le reste à faire devrait être à 0.
Cela permet ainsi chaque jour de vérifier si l’on suit toujours cette courbe (auquel cas le sprint se passe bien) où si l’on dérive (au dessus de la courbe idéal = retard, en dessous = en avance).

En l’état, chaque fin de journée, si l’équipe « suit la courbe », c’est à dire qu’elle réduit bien le reste à faire comme sur la courbe idéale, elle se trouve visuellement toujours en dessous de la courbe. A l’inverse, être sur la courbe signifie donc avec 1j de retard finalement…

Pour palier à ce problème graphique, si l’on configure la disponibilité de l’équipe à 0 le dernier jour, on constate que la courbe finit bien à 0.
Néanmoins, cette astuce fausse la disponibilité totale de l’équipe (1 journée en moins x 2 développeurs) dont nous nous servons pour confirmer la tenue du sprint lors de son lancement après la planification du sprint.

S’agit-il d’un bug ? Ou bien d’une mauvaise utilisation de notre part de cette fonctionnalité ?

Merci d’avance pour votre aide.

Thibault

• Ce sujet a été modifié le il y a 3 années et 2 mois par tplet.

[Nicolas Noullet]

Bonjour Thibault,

Merci pour votre message détaillé, nous en comprenons très bien la teneur car c’est une reflexion que nous avons eue lors de l’implémentation de ce graphique il y a maintenant plusieurs années.

Votre interprétation est bonne : la courbe représente le reste de disponibilités en début de journée. Il aurait été trop complexe et trop peu fiable de rendre ce point dynamique au fur et à mesure de l’avancée de la journée, donc nous étions face à deux options : prendre le reste de disponibilités en début de journée, ou en fin de journée, et nous avons choisi la première.

Concernant votre pratique : « nous utilisons la courbe idéale comme une cible de fin de journée », la question n’est pas si simple. Elle mérite reflexion, indépendamment de comment est générée cette courbe « idéale » (ici par les disponibilités, ou juste une droite partant du total).

Le problème vient du fait qu’on considère en général comme idéale la droite décroissante partant du total et allant jusqu’à 0. En fait conceptuellement elle est idéale dans le sens « dans un monde parfait », mais elle n’est pas idéale dans le sens « il faut coller à la courbe ».

En effet, la courbe implique une utilisation à 100% des « ressources », ou dit autrement elle ne prend en compte aucun mou, aucune marge de manoeuvre. Cela veut dire qu’au moindre écart on est au dessus de la courbe et on risque fortement de ne pas finir le travail prévu à la fin du sprint.

Ainsi, une vraie courbe « idéale à suivre » serait plutôt une droite qui terminerait quelques jours avant la fin du sprint (le nombre jours par rapport à la durée du sprint représenterait alors le mou qu’on se donne). Cependant l’intérêt d’une telle courbe seule serait limité : si on passait au dessus on aurait alors du mal à voir si on peut encore finir.

Le plus intéressant serait donc de combiner les deux et de créer une zone entre ces deux courbes (la vraie courbe idéale + la courbe qui va à 0 au dernier jour) et ainsi bien montrer la « cible ».

Pour en revenir à nos disponibilités, d’après ces observations elle ne doit pas constituer une cible. Elle représente les disponibilités restantes, c’est tout. L’objectif serait d’être assez largement en dessous, surtout au début du sprint, afin d’avoir du mou. Notre outil incorpore d’ailleurs cette notion de mou sur les disponibilités mais elle n’est pas prise en compte dans le graphique pour limiter sa complexité.

Et pour revenir à la question initiale, dans la pratique les Daily Scrum se font très souvent le matin pour faire le plan d’action de la journée. Si on regarde le graphique à ce moment là et compte tenu de notre choix, alors il montrera le travail total restant ainsi que les disponibilités totales restantes pour la même durée. Par contre au fur et à mesure que la journée avance les données ne seront plus synchronisées. Il n’est pas certain que l’on referait le même choix aujourd’hui, mais compte tenu des équipes qui ont pris l’habitude de l’utiliser, le changer aurait probablement un coût supérieur à la valeur apportée.

Dans tous les cas nous ne recommandons par d’altérer les saisies pour que la courbe tombe bien à zéro, car elle n’est effectivement pas censée y arriver dans l’état actuel des choses !

Pour résumer : la fonctionnalité est certainement imparfaite mais pas autant qu’elle peut le sembler. De plus, indépendamment de cela, je vous recommande de changer la manière d’interpréter les courbes soit disant « idéales », non plus comme une cible mais une barrière dont il ne faut pas se rapprocher !

[tplet]

Bonjour Nicolas,

Merci pour votre réponse.
Votre dernière phrase est particulièrement pertinente : considérer cette courbe comme une barrière à ne pas dépasser et le constater lors de la daily en début de journée.
Si l’on tient compte du mou (c’est vrai que j’ai perdu l’habitude ; à tord ; de l’utiliser, en utilisant d’autres astuces plus flou, comme considérer des journées de 6h dans l’outil au lieu de 7 ou 8), alors la courbe arrivera bien à 0 avant le dernier jour 🙂

Merci encore.

Thibault

[Auteur]

Messages