Pour quelle raison l’estimation d’un Backlog augmente-t-elle ?

Pour quelle raison l’estimation d’un Backlog augmente-t-elle ?

J’identifie deux origines possibles permettant d’expliquer pourquoi une estimation d’un backlog peut évoluer, et donc augmenter :

  • Le travail à faire a réellement augmenté
  • L’estimation du travail a été ajustée (au sens rendue « plus juste »)

Figure 1 : origine de l’augmentation de l’estimation du BACKLOG

Le travail a faire a réellement augmenté

La première hypothèse est que la liste des fonctionnalités à réaliser a augmenté.

 

Figure 2 : Origine d’une augmentation du travail à faire

Les changements les plus évidents de cette catégorie sont les ajouts / suppression de fonctionnalités. Et ils sont simples à expliquer et à comprendre, voire à faire arbitrer.

  • Des nouvelles idées, de nouvelles fonctionnalités

Malheureusement, les évolutions de backlog en Agile sont souvent plus subtiles. J’ai pu observer par exemple des augmentations liées à :

  • Une complexification des fonctionnalités, des détails luxueux : par exemple en ajoutant un workflow, de nombreuses règles de gestion, des formats d’affichages, des aides à la saisie, etc.
  • Des fonctionnalités « implicites » : qui ont été identifiées et ajoutées au backlog depuis le démarrage, mais qui implicitement faisaient déjà partie du périmètre
  • Des fonctionnalités de grosses tailles qui n’ont pas encore été affinées, et qui selon la loi de Pareto, contiennent probablement 20-30% de détails nécessaires mais qui sont considérées globalement comme « indispensables »

L’estimation a augmenté

La seconde origine possible est un ajustement de l’estimation. Dans ce cas de figure, même si la quantité de fonctionnalité à traiter n’a pas changé, l’estimation a quant à elle bien augmenté.

Je recommande la lecture de l’article suivant sur le blog d’Olivier My pour mieux comprendre à quoi sert l’estimation, et pourquoi un mouvement est apparu ces dernières années : #NoEstimates. http://oyomy.fr/2018/10/estimation-et-agilite-un-paradoxe/

Pour expliquer ce phénomène je m’appuierai sur la définition d’une estimation selon trois catégories :

  • L’estimation essentielle : l’effort à produire une fonctionnalité
  • L’estimation indispensable : l’effort indispensable pour permettre à la fonctionnalité de fonctionner (exemple : avoir une Gateway d’API si on veut créer une API)
  • L’estimation accidentelle : l’effort nécessaire pour réaliser le travail dans le contexte (exemple : processus de validation, gestion des contributions, réunions, compétences nécessaires…)

Si l’estimation essentielle a peu de raison d’évoluer, les deux autres catégories vont avoir naturellement tendance à augmenter, surtout au cours des premiers sprints, car l’équipe va découvrir son environnement.

Figure 3: Origine d’une augmentation de l’estimation

En synthèse, le fait d’avoir réalisé quelques sprints de fabrication a permis à l’équipe de prendre en compte de nouveaux éléments de complexité accidentelle et indispensable :

  • Contraintes de l’architecture
  • Contraintes de l’organisation
  • Risques
  • Montée en compétences technique ou fonctionnelle
  • Contraintes de process
  • Contraintes de documentation
  • Pression sur l’équipe
  • La manière d’estimer a changé (personnes différentes, …)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.