Variation de périmètre

Un burndown chart de release donne une bonne indication du travail qui reste à faire. En y ajoutant la consommation du budget, on obtient des indicateurs permettant de répondre à des questions fondamentales de la gestion d'un projet : où en sommes-nous dans l'avancement du projet, combien de budget avons-nous consommé ?

Seulement, et c'est normal avec une méthode agile, le périmètre initial, représenté par le point de départ d'un burndown chart, évolue toujours. Je définis ici le périmètre comme le total des points des éléments qui constituent le backlog pour une release.

Il évolue toujours, sur tous les projets auquel j'ai participé. La raison la plus évidente est l'ajout d'une nouvelle story qui n'avait pas été prévue au début du projet. Il y en a de nombreuses autres :

  • la décomposition, suivie d'une estimation. Il est fréquent que le total des points des éléments décomposés ne soit pas identique au total estimé pour l'élément avant décomposition
  • la suppression d'un élément. Il arrive qu'on décide de le reporter pour une prochaine release
  • une ré-estimation d'un ou plusieurs éléments du backlog qui avaient été mal compris
  • un élément qu'on n'avait pas encore estimé, parce qu'on n'avait pas eu le temps et/ou parce qu'il n'était pas prioritaire. Le simple fait de lui donner une estimation ajoute des points au total et modifie le périmètre.

Le burndown chart classique ne permet pas de voir l'évolution de périmètre. Pour l'avoir, il convient simplement de tenir compte de la vélocité. A la fin de chaque sprint, cela revient à faire 2 mesures : le reste à faire et la vélocité du sprint qui se finit. Les deux comptées en points.

Par exemple :

  • fin du sprint 0 : 100 points à faire dans le backlog de produit
  • fin du sprint 1: 82, vélocité 16
  • fin du sprint 2 : 64, vélocité 19
  • fin du sprint 3 : 56, vélocité 18
  • fin du sprint 4: 30, vélocité 20

Cela permet de savoir que pendant le sprint 3, l'évolution de périmètre a été de 18 - (64-56) , soit une augmentation de périmètre de 10 points. Au contraire pendant le sprint 4, le périmètre a diminué de (56-30) - 20, soit 6 points.

Cela peut se voir un graphique, en voici un exemple :

En rouge la courbe de reste à faire, le burndown classique. En bleu, le reste à faire si le périmètre était resté constant, obtenu simplement en utilisant la vélocité à partir du reste à faire au départ.

Commentaires

1. Le lundi 13 octobre 2008, 19:35 par zorro

une question :

on représente souvent les burndown chart de façon lineaire alors qu'on représente les burn-up sous forme de courbe en S
les deux ne sont-elles pas tout simplement inverse donc pourquoi les burndown n'ont pas une forme en S inversée ?
faudrait-il pour cela avoir beaucoup d'itérations ?
www.aubryconseil.com/dotc...


Claude : hello zorro. Non un burnup qui cumule la vélocité et un burndown ne sont pas symétriques, justement parce que le burndown inclut la variation de périmètre. Quant aux courbes en S, elles sont plutôt un modèle associé à la valeur me semble t-il. Ce qui n'est pas le sujet des burnup ou burndown. On pourrait avoir une forme en S en considérant une équipe qui apprend (vélocité faible), puis augmente sa vélocité, puis stagne suite à une dette technique, par exemple.
2. Le mercredi 12 novembre 2008, 12:09 par zorro

J'ai toujours du mal a saisir

"le burndown inclut la variation de périmètre"
mais le burnup aussi, non ? => "La courbe montre le cumul de ce qui est fini." (billet du 9/06/07); ce qui est fini inclut bien la variation de périmètre.
Toutes les courbes n'incluent-elles pas la variation de périmètre ?
Et pour cause : quel serait l'intérêt d'exclure les variations de périmètre, inhérente à la méthode ?

"Quant aux courbes en S, elles sont plutôt un modèle associé à la valeur (earned value) me semble t-il"
Pourtant, dans le lien que j'ai indiqué dans mon 1er commentaire (billet du 9/06/07), le premier graphe indique bien "BURNUP" et il présente une forme en "S"

"Ce qui n'est pas le sujet des burnup ou burndown"
Donc les "points" indiqués en ordonnées sont des efforts et non des valeurs client (billet du 9/06/07) ?
Or le deuxième graphe montre le "cumul à faire" pour visualiser la variation de périmètre. Dans ce cas, n'est-ce pas justement les "points de scénarios" au sens utilisateur et non les efforts estimés par les développeurs ?

Désolé je m'y perds avec ces courbes.

Merci !


Claude : je vais essayer d'éclaircir tout ça dans un prochain billet.