Explorer l’estimation

On considère souvent qu’estimation et équipes agiles ne font pas bon ménage. Dans les organisations non agiles, la plupart des travaux sont portés par l’estimation. Cette dernière, après avoir été annoncée par le fournisseur (interne ou externe) est souvent prise comme un engagement de coût du travail à réaliser. Nous voyons d’ailleurs souvent des relations clients/fournisseurs s’envenimer assez rapidement autour de ce sujet.

Du fait, lorsqu’on parle de transformation agile, le sujet de l’estimation revient assez facilement sur le tapis : comment l’équipe va-t-elle prendre un engagement raisonnable ? Comment m’assurer, entant que responsable de l’entreprise, que l’équipe n’est pas entrain de brûler du gaz pour rien ?

La première chose à remettre en perspective est que le but d’une équipe agile n’est pas de tenir un engagement de dépense (en temps ou en coût) mais bel et bien de tenir un engagement de production de valeur. De fait, à tout moment de la vie d’un projet agile, si la valeur attendue a été correctement identifiée et documentée (suivi sur le long terme), on sait si l’équipe produit la valeur attendue et donc si la dépense en temps vaut le gain obtenu.

Cependant, notamment dans les pratiques SCRUM, on demande à l’équipe de prendre un engagement sur ce qu’elle va être capable de produire sur la période de temps qui arrive (itération ou sprint). De fait, les équipes ont alors souvent recours à un système d’estimation relative.

En effet, plutôt que de discuter en temps, elles comparent le travail qu’elles ont été capables de produire sur l’itération précédente à celui qui leur est demandé sur l’itération qui arrive et décident si elles peuvent s’engager.

Bien sûr, l’équipe agile ne se contente pas d’un engagement sur le contenu du sprint, elle regarde les plus petits éléments contenus dans le sprint (généralement des User Stories ou des tâches) et les comparent à celles qu’elle a déjà réalisées.

Pour faciliter le travail de l’équipe, et la comparaison entre des éléments d’origines ou de spécialités différentes, l’équipe utilise une valeur numérique pour représenter l’effort qu’elle pense devoir déployer pour répondre au besoin décrit. Du fait, elle met souvent en place un étalon lui permettant de garder en tête les éléments les plus significatifs passés et de rapidement comparer le travail qu’ils ont devant eux avec ceux déjà réalisés.

On a parfois des équipes qui s’affranchissent de ces estimations en « points d’effort » et avancent vers le « No Estimate », mais nous n’allons pas détailler cette pratique ici.

L’avantage de travailler avec une équipe agile, qui met en place de la transparence et donne de la visibilité sur le travail réalisé, c’est que du fait le responsable du projet ou du produit (souvent un PO), a à sa disposition tous les éléments pour proposer des projections de ce qu’il reste à produire.

En effet, dans le cadre d’une équipe avec un backlog assez détaillé, le PO peut regarder la quantité de sujets qui sortent à chaque sprint et, en fonction du nombre de sujets présents dans le backlog, proposer une projection du nombre de sprints restants pour réaliser ce qu’il reste à créer. On peut alors faire le travail de manière détaillée en fonction des différents pans fonctionnels présents dans le backlog.

Cependant, toutes les équipes agiles ne sont pas en mesure d’obtenir un backlog détaillé ou d’avoir un niveau de découpe des sujets constant. En effet, certains sujets demandent beaucoup d’effort et d’autre très peu… On voit souvent les POs utiliser une estimation de haut niveau en taille de TShirt puis, en fonction de la capacité à produire de l’équipe à l’instant T, mettre à jour leur projection au fur et à mesure de la vie du produit.

C’est assez facile pour l’équipe dans ce cas-là: en effet, plutôt que de devoir sortir des abaques, comme c’était le cas dans les projets non agiles, pour obtenir une roadmap (qui la plupart du temps était fausse de toute façon), ils peuvent rapidement envisager les sujets dans le backlog et tomber d’accord sur les tailles de TShirt. Le PO organise ces sessions aussi souvent que nécessaire (dans l’affinage du backlog) et met à jour ces projections très facilement.

Vous trouverez plus d’informations sur ce sujet dans la vidéo d’Henrik Kniberg (traduite par Florent Lothon) : La gestion de produit agile en deux mots https://www.youtube.com/watch?v=3qMpB-UH9kA