L’estimation
Dans presque toutes les équipes, il arrive, à un moment donné, quelqu’un venu de nulle part, qui va demander “ça coûte combien ?” ou bien “ça sera livré quand ?” … C’est à ce moment-là que cette équipe va commencer cet exercice périlleux qu’est l’estimation !
Pourquoi estimer ?
Pour aider l’équipe
Tout d’abord, il faut voir l’estimation comme une aide et non comme une contrainte ! Cela peut aider l’équipe à se piloter, on parlera de vélocité. C’est un indicateur qui permet de mesurer tous les items terminés. Cela permettra d’avoir de l’information sur l’avancement dans le projet et aussi de planifier la suite des développements. L’équipe peut jouer aussi dessus pour essayer de se challenger et valider des actions d’amélioration continue concernant leur productivité. Mais pour cela, l’équipe estimera chaque item qu’elle a faire.
Pour donner de la visibilité aux clients
Comme expliqué en introduction, nous avons besoin d’estimer pour répondre à une question cruciale pour nos clients : “quand est-ce que ça sera livré ?”. Il est important de donner de la visibilité à ceux qui en ont besoin. Dans une démarche agile, nous collaborons de manière transparente, donc il ne faut pas hésiter à transmettre ces estimations à ses clients.
Pour prioriser
Estimer permettra de connaître le coût d’un item à faire. Ainsi un Product Owner pourra s’appuyer sur cette information pour prioriser son product backlog. Dans une volonté de maximiser la valeur ajoutée, il aura tendance à favoriser, au début, des items qui coûtent peu, mais qui apportent beaucoup de valeurs aux utilisateurs ! De plus, cela permettra au product owner de limiter le risque. Plus c’est gros, plus c’est risqué. Un petit item en cas d’échec aura un impact moins fort qu’un gros !
Qui estime ?
Il est important que celui qui fait soit celui qui estime ! Qui de mieux que l’équipe de réalisation, qui fera appel à toutes ses connaissances et à toute son expertise pour estimer ce qu’il y a à faire. C’est un exercice important, qu’il ne faut pas prendre à la légère et qui aura des conséquences sur la suite du projet.
Comment estimer ?
Les unités qui existent
Il existe plusieurs unités pour estimer le travail à faire.
- Les heures
- Les story points, on utilisera la suite de Fibonacci (1, 2, 3, 5, 8, 13, …)
- Les tailles de t-shirt (XS, S, M, L, XL, XXL)
C’est une liste non exhaustive. Vous pouvez trouver votre propre unité d’estimation. Il ne faut pas oublier que c’est censé vous aider alors à vous de vous adapter et de trouver le meilleur outil pour votre équipe.
Pourquoi ne pas utiliser les heures ?
On pourrait se dire qu’estimer en temps serait plus simple dans de la gestion de produit. Effectivement, nos clients nous demandent des dates de livraison… Mais il est préférable d’éviter, car en tant que personne nous avons beaucoup de mal à utiliser cette unité, à se représenter mentalement ce que vaut par exemple 1h. Le plus souvent quand on nous demande une date, on ne veut pas une estimation, mais une réponse exacte… Nous avons tous déjà entendu “j’arrive dans 5 minutes”. Nous le savons, la personne n’arrive jamais dans 5 minutes…
En plus de ça, nous n’avons pas la même représentation de l’échelle du temps. Reprenons l’exemple des 5 minutes, on l’utilise souvent pour exprimer quelque chose de rapide, mais si je vous demande d’attendre 5 minutes à ne rien faire, vous allez sans doute trouver le temps long ! Selon les contextes, les personnes, etc., le temps peut être long ou bien très court, il n’aura pas la même représentation.
En estimation, nous parlons d’être globalement juste plutôt que précisément faux.
C’est pour cela qu’il est préférable de favoriser une unité tel que le story point. Dans ce cas-là nous utiliserons la suite de Fibonacci.
OK, mais comment ?
Le story point, la suite de Fibonacci, est une échelle que vous pourrez plus facilement vous approprier. Vous arriverez plus facilement à parler de la même chose. Ainsi vous trouverez pour votre équipe, une référence commune qui sera la base de toutes vos estimations. En effet, nous allons utiliser l’estimation relative, c’est-à-dire en comparant les items. Est-ce que cette tâche est plus petite, plus grosse ou équivalente à cette autre tâche ?
Lors de cet exercice, il faut tout prendre en compte, la complexité, l’inconnue, la répétition, et se baser sur la référence de l’équipe. On estime au global tout ce qu’il y a à faire, c’est-à-dire tout ce dont on aura besoin pour mettre cette tâche dans la colonne “Done” de notre workflow. Par exemple, on pourrait avoir du développement, de l’analyse, du test, etc.
On n’oublie pas que nous estimons quelque chose à faire et non pas le temps qu’on va y passer ! Si on prend deux développeurs d’une même équipe, avec des expériences différentes, l’un pourra sans doute aller plus vite que le second, plus junior, alors qu’en story point nous avons la même valeur. Nous avons une même tâche à accomplir, qui est la même pour les deux, mais deux personnes différentes !
Planning poker
C’est un très bon atelier pour une équipe qui souhaite estimer le travail à faire. Cela permettra aussi à l’équipe de collaborer et de partager les connaissances. L’autre gros avantage est qu’il permettra à chaque membre de s’exprimer.
Cela se déroule en plusieurs étapes :
- Le Product owner présente un item de son backlog et partage son besoin à l’équipe de réalisation
- L’équipe peut poser ses questions afin de s’approprier le besoin
- Chaque membre choisit une carte, mais ne la dévoile pas tout de suite
- Tous les membres dévoilent leur carte en même temps
- S’en suit une discussion sur le choix de l’estimation et de la compréhension du besoin
- On peut refaire un tour, aller à l’étape 2), jusqu’à ce que l’équipe trouve un consensus
Zenika organise son premier ZenikAgile Day le jeudi 5 décembre prochain !
Nous recherchons des speakers pour animer des conférences et ateliers. Pour plus d’informations, rendez-vous sur cet article !
