Zorro est revenu

La valeur et le coût

Dans son deuxième commentaire de mon billet sur la variation de périmètre, Zorro revient sur les courbes et s'y perd entre les notions de valeur, d'effort et de coût. J'essaie d'éclaircir.

Le burndown chart montre l'effort qui reste à faire. Il est obtenu en collectant le nombre de points des éléments qui restent à faire dans le backlog de produit. Exemple :

  • début du sprint 1 : 100 points à faire
  • fin du sprint 1: 82
  • fin du sprint 2 : 64
  • fin du sprint 3 : 56
  • fin du sprint 4: 30

Il ne permet pas de connaitre la part due au travail accompli et celle venant du changement de périmètre dans le backlog. Pour visualiser ces informations, il est nécessaire d'avoir 2 séries, que montrera le diagramme correspondant. Un diagramme possible est le burnup à 2 courbes. La première série montre le nombre de points des éléments dans le backlog de produit, ceux qui sont faits plus ceux qui restent à faire. La deuxième montre l'effort fait, obtenu par cumul des vélocités.

  • début du sprint 1 : 100 points dans le backlog de produit. Les 2 premières valeurs du burnup sont 100 et 0
  • fin du sprint 1: 82, vélocité 16. Les 2 valeurs sont 98 (100-82+16) et 16
  • fin du sprint 2 : 64, vélocité 19. Les 2 valeurs sont 99 (98 - et 35 (16+19)
  • fin du sprint 3 : 56 vélocité 18. Les 2 valeurs sont 109 et 53
  • fin du sprint 4: 30, vélocité 20. Les 2 valeurs sont 106 et 73

La première série représente l'évolution du périmètre à chaque sprint : 100, 98, 99, 109, 106
La deuxième série montre le cumul de vélocité : 0, 16, 35, 53, 73
Le reste à faire est la surface entre les 2 courbes. Le projet devrait se terminer au croisement des 2 courbes.

Le burndown et le burnup dont je viens de parler utilisent tous les 2 des points. Les points représentent une estimation de la taille d'un élément, donc du travail nécessaire pour le finir. Ils sont généralement obtenus par des séances de planning poker.

Ces 2 rapports sont donc bâtis sur une estimation du travail à faire. Les points sont utilisés comme unité arbitraire pour éviter l'emploi explicite des euros.

Pour répondre à Zorro, il n'y est pas question de valeur et pourtant la confusion est parfois faite. La valeur d'un élément du backlog est ce qu'elle rapporte avec le point de vue des utilisateurs. Estimer la valeur est un problème très difficile, à tel point que je n'ai pas encore rencontré de projets où tous les éléments du backlog de produit avaient une valeur numérique associée.

On peut simplifier la difficulté en utilisant des valeurs relatives. C'est un peu ce qui est fait implicitement quand on ordonne les éléments du backlog de produit. Cette simplification est suffisante pour obtenir un planning de release crédible dans les cas simples.

Commentaires

1. Le lundi 17 novembre 2008, 13:42 par zorro

Merci, c'est clair.
Il fallait donc comprendre "points" comme des unités d'effort/cout et non de valeur métier.

Mais qu'en est-il de la forme en "S" des courbes ?
(voir questions précédentes :www.aubryconseil.com/dotc...

Les burnup représentaient une forme en "S" alors qu'il s'agit bien d'effort
Ou était-ce une illusion d'optique ?
;-)
Dans les approches cascades, on peut assimiler les burnup aux courbes budgétaires qui sont en forme de S
Est-ce le fait d'être agile et itératif qui fait qu'un burn-up devient linéaire ?

2. Le mardi 21 avril 2009, 09:12 par Pascal

Bonjour,

ScrumMaster néophyte, j'ai cru bon honorer nos engagements pris en début du sprint 1 aux détriments de sa durée fixée à 3 semaines. Résultat : estimation 21 - décomposée au niveau tâche cela donnait 102 heures. Nous finalisons le sprint avec 230 heures au compteur (y compris 24 heures liées à une évolution de périmètre). Comment calculer la vélocité dans ce cas en sachant qu'à la date fatidique, tout avait commencé, mais rien n'avait été achevé ? Pouvez vous me guider pour mon second sprint ?

Dans l'attente de vous lire

Pascal

3. Le lundi 27 avril 2009, 01:37 par Oaz

@Pascal,
Je me permets un commentaire (et même 2)
- A mon avis, dans votre situation, il n'y a pas grand intérêt à calculer une quelconque vélocité car le développement n'est pas maîtrisé. Aucun chiffre de vélocité ne serait suffisamment bon pour présenter une utilité.
- Le problème se situe dans le "tout avait commencé" : pourquoi "tout" commencer sans être raisonnablement sûr de "tout" finir ? Pourquoi ne pas commencer qu'une seule chose ?

4. Le mardi 28 avril 2009, 15:21 par Pascal

Merci pour ces commentaires qui m'ont d'ailleurs été également rapportés par Claude. Je vais resserrer le coatching dans le sprint suivant afin de ne pas commencer une storie si la précédente n'est pas finalisée