Raisons pour lesquelles l'équipe entière doit participer aux estimations
Auteur : Mike Cohn
Source : Why the Whole Team Should Participate When Estimating
Date : 18/07/2017
Traducteur : Fabrice Aimetti
Date : 19/07/2017
Traduction :
Une pratique très courante est de faire estimer l'effort à ceux qui font le travail, plutôt que de demander à un autre groupe, ailleurs, d'estimer l'effort.
Mais lorsqu'une équipe agile estime les éléments du backlog produit, l'équipe ne sait pas encore qui va travailler sur chacun des éléments. Elle le déterminera soit lors de la planification de l'itération (sprint), soit en temps réel lors des mêlées quotidiennes.
Ce qui signifie que l'équipe entière doit participer à l'estimation de chaque élément du backlog produit. Mais comment quelqu'un, qui n'a pas la compétence pour fabriquer l'un des éléments du backlog produit, peut-il contribuer à son estimation ?
Avant de répondre à cette question, j'ai besoin de décrire très rapidement ce qu'est le Planning Poker, une approche courante d'estimation des éléments du backlog produit. Si vous êtes déjà familier avec le Planning Poker, vous pouvez sauter le prochain chapitre.
Planning Poker
Le Planning Poker est une approche d'estimation collaborative basée sur le consensus. Il démarre lorsque le Product Owner ou une Partie Prenante clé présente à l'équipe un élément à estimer. Les membres de l'équipe sont encouragés à poser des questions et à discuter de l'élément pour comprendre le travail à estimer.
Chaque membre de l'équipe tient dans ses mains un jeu de cartes de poker sur lequel sont inscrites les estimations qui peuvent être utilisées par l'équipe. Toutes les valeurs sont possibles, mais il est généralement conseillé d'éviter d'être trop précis. Par exemple, estimer un élément à 99 et un autre à 100 est extrêmement difficile puisque que 1% d'augmentation de l'effort semble impossible à percevoir. Les valeurs communément utilisées sont 1, 2, 3, 5, 8, 13, 20, 40 et 100 (une variante de la suite de Fibonacci) ou 1, 2, 4, 8, 16 et 32 (on double la valeur précédente).
Une fois que les membres de l'équipe ont bien compris l'élément à estimer, chaque estimateur choisit une carte qui reflète son estimation. Puis tous les estimateurs montrent leurs cartes en même temps. Si toutes les cartes montrent la même valeur, cela devient l'estimation de l'équipe pour le travail à réaliser. Sinon, les estimateurs discutent de leurs estimations en écoutant surtout ceux qui ont donné la valeur la plus haute et la valeur la plus basse.
Si vous n'êtes pas familier avec cette façon d'estimer les éléments du backlog produit, vous voudrez peut-être lire cet article sur le Planning Poker (fr) avant de continuer.
Comment peut-on participer sans avoir les compétences nécessaires ?
Après avoir partagé la compréhension de ce qu'est le Planning Poker, voyons comment chaque membre de l'équipe peut contribuer pour estimer l'effort sachant qu'il ne sera potentiellement pas impliqué. Par exemple, prenons un ingénieur base de données à qui on demande d'estimer un élément du backlog produit qui inclura du développement JavaScript pour le front-end et du développement Ruby on Rails pour le backend, puis du test.
Comment cet ingénieur base de données peut-il aider à estimer cet élément du backlog produit ?
On peut donner trois raisons pour lesquelles c'est possible... et souhaitable.
1. Le Planning Poker ne consiste pas à voter
Lorsqu'ils jouent au Planning Poker, les participants ne votent pas pour leurs estimations préférées. L'équipe ne prendra pas sa décision sur l'estimation qui a le plus de votes. On accorde plutôt la crédibilité qui lui est dû à chaque estimateur. Si un développeur a écrit le code initial qui doit être modifié et que l'on doive retourner dans ce code quelques jours après, l'équipe doit accorder plus de crédit à l'estimation de ce développeur qu'à l'estimation d'un développeur qui n'a jamais été impliqué dans cette partie du système.
Cela signifie que chaque membre de l'équipe peut estimer, mais que l'équipe donnera plus de poids aux opinions de ceux qui sont plus sachants sur le travail à réaliser.
2. Les estimations sont relatives et c'est plus facile
Dans le Planning Poker, les estimations doivent être relatives plutôt que absolues. Ainsi l'équipe pourra dire : "Cet élément prendra deux fois plus de temps que cet autre élément, mais nous ne pouvons pas estimer le nombre réel d'heures que prendra chaque élément".
Par exemple, cet article contient une illustration. J'ai donné une brève description à mon graphiste de de que j'avais en tête et il a crée l'illustration. La plupart de mes articles n'ont qu'une seule illustration. Même si je ne dispose pas de dons artistiques, je peux chaque semaine estimer l'effort à consacrer pour créer des illustrations qui se ressemblent à peu près.
Evidemment, certaines illustrations réclament davantage d'efforts, et d'autres peuvent réutiliser quelques éléments d'anciennes illustrations. Mais la plupart sont suffisamment proches pour que j'estime qu'elles valent le même effort.
Mais certains articles comprennent deux images. Même si je n'ai aucun don artistique, je peux affirmer que la création de ces deux images prendra environ deux fois plus longtemps qu'une seule.
Donc, on ne demandera pas à un testeur d'estimer combien d'heures mettra un développeur pour coder quelque chose. Mais on demandera au testeur d'estimer ce développement relativement à d'autres développements.
Cela reste difficile mais les estimations relatives sont plus faciles que les estimations absolues. Et rappelez-vous qu'à cause du point 1. ci-dessus, on n'accordera pas autant de crédit à une personne dont les compétences ne seront pas mises à l'oeuvre qu'à celle qui les utilisera.
3. Tout le monde contribue, même s'il n'estime pas
Je souhaite que chaque personne de l'équipe participe à la réunion d'estimation. Mais cela ne veut pas dire que tout le monde estime chaque élément.
Même si l'estimation relative est plus facile que l'estimation absolue, il y aura toujours des moments où une personne ne sera pas capable d'estimer un élément particulier du backlog produit. Cela arrivera notamment lorsque les compétences de la personne ne sont pas nécessaires pour cet élément. Mais cette personne pourra toujours contribuer à la discussion.
Parfois, la personne dont les compétences ne seront pas nécessaires sur un élément particulier du backlog produit, sera la plus capable pour poser des questions sur l'élément, pour montrer que des hypothèses ne sont pas prises en compte, ou tout simplement pour voir des choses que les autres ont oublié.
Par exemple, un développeur base de données dont les compétences ne sont pas utilisées pour fabriquer une élément particulier du backlog produit sera peut-être celui qui se rappellera que :
- l'équipe a promis de nettoyer ce code la prochaine fois qu'elle y retournerait
- il y a un impact non vu sur les états de reporting
- lorsque l'équipe a réalisé un élément similaire un an plus tôt, cela avait consommé beaucoup plus de temps que toutes les prévisions annoncées
- et ainsi de suite.
Le développeur base de données devra connaître ces choses et poser ces questions même s'il ne peut pas personnellement estimer leur impact sur le travail.
Quelques exemples
Pour donner quelques exemples, reprenons le rôle de l'ingénieur base de données lors de l'estimation d'un élément du backlog produit qui ne comporte pas de travail sur la base de donnée. Voici quelques exemples de choses que ce membre de l'équipe pourrait dire et qui ajouterait de la valeur lors de l'estimation de cet élément du backlog produit :
- "Je maintiens cette estimation haute parce qu'il me semble qu'il y a un effort de développement conséquent à produire. Il me semble que cela représente deux fois plus de travail que cet autre élément du backlog."
Dans ce cas, l'ingénieur base de données fait une estimation relative de l'effort. C'est vraisemblablement basé sur les choses dites par les développeurs. Dans certains cas, l'ingénieur base de données se trompera lors de son évaluation. Mais cela ne veut pas dire que l'opinion de cette personne ne doit pas être créditée. L'opinion de l'ingénieur base de données doit être créditée à la hauteur de sa contribution (qui peut être grande ou petite). - "Etes-vous sûr qu'il y a autant de travail ? Il y a deux sprints, je pensais que vous, les développeurs, vous alliez refactorer cette partie du système. Si ça s'était produit, est-ce que cela ne serait pas plus facile aujourd'hui ?"
Ici l'ingénieur base de données apporte des informations que les autres n'ont pas rappelé ou pris en compte. Cela peut avoir ou non de la valeur. Parfois cela en a. - "Etes-vous sûr que cela ne nécessite pas plus de travail ? Avez-vous pris en compte le besoin de faire ceci ou cela ?"
Dans ce cas, l'ingénieur base de données met le doigt sur un travail que les autres ont éventuellement négligé. Si ce travail est pertinent, cela doit se refléter dans l'estimation.
Lorsque tout le monde participe, cela accroît le sentiment d'adhésion
Il y a une dernière raison pour laquelle je suggère que l'équipe entière participe à l'estimation des éléments du backlog produit, surtout avec une technique telle que le Planning Poker : en procédant ainsi, on augmente le sentiment d'adhésion aux estimations par les membres de l'équipe.
Lorsque quelqu'un d'autre estime quelque chose pour vous ou moi, nous ne nous sentons pas engagés par cette estimation. Cela peut être ou non une bonne estimation. Mais si ce n'est pas le cas, ce n'est pas de notre faute. Nous ferons plus de choses pour respecter une estimation que nous avons donnée, plutôt qu'une estimation amenée par quelqu'un d'autre.
Nous souhaitons que toute l'équipe participe à l'estimation du travail de l'équipe. Vous ne saurez jamais à l'avance qui posera une question pertinente sur un élément du backlog produit. Parfois, c'est l'un des membres de l'équipe qui travaillera sur cet élément. Mais d'autres fois ces questions viendront de quelqu'un qui n'a pas les compétences nécessaires sur cet élément.
Donc, même si chaque membre de l'équipe ne doit pas fournir une estimation pour chaque élément, chaque membre de l'équipe doit participer aux discussions accompagnant chaque estimation. L'équipe est encore meilleure lorsque tous ses membres travaillent ensemble pour le bien du produit, de son estimation à sa livraison.
Quel est votre retour d'expérience ?
Quelle a été votre retour d'expérience lorsque vous avez impliqué l'équipe entière lors de l'estimation des éléments du backlog produit ? Avez-vous trouvé des bénéfices à faire participer tout le monde même si chacun n'avait pas ses compétences utilisées pour un élément particulier du backlog produit ?
