Articles

Comment gérer les désaccords pendant le Planning Poker

Une équipe agile diversifiée assise autour d'une table lors d'une session de Planning Poker, levant des cartes avec des estimations différentes montrant le désaccord, avec un scrum master facilitant la discussion Vous révélez les cartes. Un développeur a joué un 3. Un autre a joué un 13. La salle devient silencieuse pendant une seconde, puis tout le monde commence à parler en même temps. Si vous facilitez le Planning Poker depuis un certain temps, vous connaissez bien ce moment. La plupart des scrum masters le traitent comme un problème à résoudre rapidement. Parvenir à un consensus, passer à la story suivante. Mais le désaccord lui-même est la partie la plus précieuse de la session entière. L'écart entre un 3 et un 13 signifie que votre équipe a des hypothèses fondamentalement différentes sur le travail, et révéler ces hypothèses avant le début du sprint est exactement ce à quoi sert l'estimation. Voici comment transformer ces désaccords en meilleurs résultats de sprint au lieu de perdre du temps.

Pourquoi les désaccords d'estimation sont précieux

Si votre équipe était d'accord sur chaque estimation immédiatement, vous n'auriez pas besoin du Planning Poker du tout. Vous pourriez simplement avoir une personne assigner des nombres. La raison de l'existence de la révélation simultanée est spécifiquement de révéler le désaccord. Quand les estimations divergent, cela signifie généralement l'une de trois choses: Complexité cachée. Un développeur voit une opération CRUD simple. Un autre voit un cas limite impliquant la concurrence ou une intégration fragile qui nécessitera une gestion prudente. Sans le désaccord, l'équipe s'engagerait sur l'estimation plus basse et découvrirait la complexité en milieu de sprint. Hypothèses différentes sur la portée. "Construire la fonction de recherche" signifie la recherche en texte intégral avec filtres et pagination pour un développeur et un simple dropdown de correspondance de chaîne pour un autre. L'écart dans les estimations révèle que les critères d'acceptation doivent être clarifiés avant que l'équipe ne commençe à construire. Exigences manquantes. Une grande dispersion signale souvent que la story elle-même est incomplète. Quand quelqu'un estime haut parce qu'il tient compte des inconnues que d'autres n'ont pas considérées, ces inconnues doivent être nommées et résolues.

La technique de discussion des valeurs aberrantes

Le geste de facilitation le plus efficace pendant le planning poker est de demander aux valeurs aberrantes de parler en premier. Après avoir révélé les cartes, commencez toujours par la personne qui a estimé le plus haut et la personne qui a estimé le plus bas. Cela fonctionne pour trois raisons:

1. Cela donne la parole aux valeurs aberrantes. Dans de nombreuses équipes, la personne qui a joué un 2 quand tout le monde a joué un 8 restera silencieuse à moins d'être spécifiquement invitée à expliquer. Elle pourrait savoir quelque chose que personne d'autre n'a considéré, ou elle pourrait mal comprendre la story. De toute façon, vous devez l'entendre.
2. Cela empêche la majorité d'écraser la minorité. Si cinq personnes ont joué un 8 et une a joué un 2, l'instinct naturel est de faire pression sur la minorité pour se conformer. Commencer avec la minorité signale que leur perspective compte indépendamment des chiffres.
3. Cela concentre la discussion. Au lieu d'une discussion libre où chacun réénonce son raisonnement, vous obtenez un débat structuré entre les deux extrêmes du spectre. Le reste de l'équipe écoute et ajuste son modèle mental.

Deux développeurs de logiciels ayant une discussion respectueuse et engagée sur un écran d'ordinateur portable, l'un pointant l'écran en expliquant son approche technique tandis que l'autre écoute attentivement, avec des cartes d'estimation visibles sur un tableau blanc

Comment faciliter la discussion des valeurs aberrantes

Utilisez ces invites spécifiques pour guider les conversations productives des valeurs aberrantes:

• À l'estimateur le plus bas: "Décrivez-nous votre approche. À quoi ressemble cette story dans votre tête?"
• À l'estimateur le plus haut: "Quels risques ou quelle complexité voyez-vous qui pourraient ne pas être évidents?"
• Aux deux: "Quelles hypothèses faites-vous sur la portée?"
• Après que les deux parlent: "Quelqu'un veut-il changer son estimation en fonction de ce que vous venez d'entendre?"

Puis revotez. La plupart du temps, l'équipe converge après une ronde de discussion des valeurs aberrantes parce que la conversation a révélé soit un malentendu de portée, soit un risque technique qui change le modèle mental de tous.

Causes communes de désaccord

Comprendre pourquoi les estimations divergent vous aide à résoudre les désaccords plus rapidement. Voici les modèles que vous verrez le plus souvent:

Compréhension différente de la portée

C'est la cause la plus courante. Deux développeurs lisent la même histoire d'utilisateur et s'imaginent un travail complètement différent. L'un interprète "ajouter des notifications" comme un message de notification dans l'application. Un autre l'interprète comme des notifications par email avec modèles, suivi de livraison et gestion de la désinscription. Comment le résoudre: Demandez au propriétaire du produit de clarifier la portée sur place. Si le PO n'est pas dans la salle, mettez la story de côté et apportez-la à la prochaine session de raffinement du backlog.

Approches techniques différentes

Deux développeurs pourraient être d'accord sur la portée mais pas sur comment la construire. L'un prévoit d'étendre un service existant. Un autre pense que le service existant ne peut pas gérer la charge et veut en construire un nouveau. Comment le résoudre: Ce n'est pas un problème d'estimation; c'est une décision de conception. Que l'équipe discute brièvement des compromis et choisisse une approche. Si cela nécessite plus de recherche, créez un spike et estimez la story à la prochaine session.

Lacunes d'expérience

Un développeur senior qui a construit des fonctionnalités similaires auparavant estime un 3. Un développeur de niveau moyen qui n'a jamais touché cette partie de la base de code estime un 8. Les deux sont honnêtes, et les deux ont raison selon leur propre expérience. Comment le résoudre: Estimez pour l'équipe, pas pour l'individu. Demandez: "Si un membre typique de l'équipe prenait cela, combien d'effort serait-ce?" Si une seule personne peut faire le travail, c'est un risque de partage de connaissances qui vaut la peine d'être signalé, mais il ne devrait pas gonfler l'estimation. L'estimation devrait refléter la complexité inhérente, pas qui se retrouve à faire le travail.

Critères d'acceptation peu clairs

Quand les stories sont vagues, les estimations deviennent des devinettes. "Améliorer les performances" sans nombre cible. "Rendre le tableau de bord plus convivial" sans maquettes. Ces stories ne sont pas prêtes pour l'estimation. Comment le résoudre: Renvoyez-les. Les stories qui ne peuvent pas être estimées doivent retourner au raffinement. Si vous voyez ce modèle fréquemment, le problème peut être dans comment les histoires d'utilisateur sont écrites. Vous pouvez également utiliser un analyseur de complexité d'estimation pour signaler les stories insuffisamment spécifiées avant qu'elles n'atteignent la table d'estimation.

Timeboxez vos discussions d'estimation

C'est là que la plupart de la facilitation échoue. Un désaccord survient, la discussion est productive pendant deux minutes, puis elle se transforme en un débat d'architecture de 15 minutes. L'équipe estime quatre stories en une heure au lieu de douze. Définissez une boîte de temps dure de cinq minutes par story. Voici comment l'appliquer: Un gros plan d'en haut d'une table de réunion avec des cartes de planning poker montrant des estimations différentes, une minuterie et des notes adhésives avec du texte de story utilisateur, transmettant un débat d'estimation structuré

Pourquoi vous ne devriez jamais faire la moyenne des estimations

Quand une équipe ne peut pas se mettre d'accord, il est tentant de faire la différence. "Nous avons un 5 et un 13, appelons-le 8." Cela semble juste et efficace. Ce n'est ni l'un ni l'autre. La moyenne cache le désaccord au lieu de le résoudre. La personne qui a dit 13 a des informations sur les risques ou la complexité qui ne disparaissent pas parce que vous avez écrit 8. Quand le sprint commence, ces risques sont toujours là, et l'équipe s'est engagée sur une estimation qui ne reflète précisément aucune perspective. La moyenne défait également l'objectif d'utiliser une échelle non linéaire comme Fibonacci. Les sauts entre les valeurs (1, 2, 3, 5, 8, 13, 21) sont intentionnellement grands pour forcer les équipes à faire des distinctions significatives. Un 5 et un 13 ne sont pas "assez proches pour se rencontrer au milieu." Ils représentent des compréhensions fondamentalement différentes du travail. Pour en savoir plus sur pourquoi les échelles de points de story sont conçues de cette façon, consultez notre analyse approfondie. Quoi faire au lieu de faire la moyenne:

• Utilisez la technique de discussion des valeurs aberrantes pour révéler la cause première du désaccord
• Si vous devez choisir un nombre sans consensus, allez avec l'estimation plus haute. Il est plus sûr de surestimer que de sous-estimer
• Si l'écart est extrême (par exemple, 2 vs. 21), la story n'est pas prête. Renvoyez-la au raffinement

Utilisez la révélation simultanée pour prévenir le biais d'ancrage

Le biais d'ancrage est la tendance à s'appuyer fortement sur la première information que vous entendez. En estimation, cela signifie que le premier nombre dit à voix haute devient l'ancre pour la pensée de tous les autres. Si un développeur senior dit "cela ressemble à un 3" avant que les cartes ne soient révélées, le reste de l'équipe s'ajuste inconsciemment vers ce nombre. Le planning poker anonyme résout cela en s'assurant que toutes les estimations sont soumises avant qu'aucune ne soit révélée. Personne ne voit le nombre de personne d'autre jusqu'à ce que tout le monde se soit engagé. Ce n'est pas juste un plus; c'est une protection structurelle contre l'un des biais cognitifs les plus bien documentés dans la prise de décision. Des outils comme Kollabe appliquent automatiquement la révélation simultanée. Les cartes restent cachées jusqu'à ce que chaque participant ait sélectionné son estimation. C'est considérablement plus fiable que les cartes physiques, où quelqu'un finit inévitablement par retourner une carte ou la tenir à un angle. Les équipes qui manquent de sécurité psychologique bénéficient particulièrement de l'estimation anonyme. Quand les développeurs juniors sentent que leur estimation honnête pourrait être jugée par les membres seniors de l'équipe, ils reviennent à ce que les seniors jouent. L'anonymat élimine complètement cette dynamique.

Quand arrêter de discuter et diviser la story

Parfois, un désaccord n'est pas un malentendu. Les deux côtés comprennent complètement la story, mais le travail est véritablement complexe et incertain. Quand cela se produit, la réponse n'est pas un débat plus long. La réponse est de diviser la story. Signes qu'une story a besoin d'être divisée plutôt que de plus de discussions:

• Les estimations s'étendent sur plus de trois valeurs de Fibonacci (par exemple, 3 à 21)
• La discussion revient continuellement à "cela dépend de..." plusieurs scénarios
• Différentes parties de la story pourraient être livrées indépendamment
• L'équipe identifie des zones de risque distinctes qui pourraient être isolées

Comment diviser efficacement: Divisez selon les lignes de valeur, pas les couches techniques. "Construire l'API" et "Construire l'UI" ne sont pas de bonnes divisions parce qu'aucune ne fournit de valeur utilisateur seule. Divisez plutôt par scénario d'utilisateur: "Chercher par nom" et "Chercher avec filtres avancés" fournissent chacun quelque chose qu'un utilisateur peut réellement utiliser. Après la division, réestimez chaque pièce. Vous constaterez souvent que la somme des parties est plus grande que l'estimation d'origine, et c'est correct. L'estimation d'origine était fausse parce que la story était trop grande pour être estimée avec précision. Les stories plus petites sont plus faciles à estimer, à construire et à vérifier.

La technique de vote de confiance

Vous avez discuté des valeurs aberrantes, vous avez revté et vous êtes arrivé à un nombre que l'équipe accepte. Mais l'acceptation n'est pas la même que la confiance. Le vote de confiance "poing de cinq" capture la différence. Après avoir atteint un consensus sur une estimation, demandez à chaque membre de l'équipe de lever simultanément un à cinq doigts:

Doigts	Signification
5	Entièrement confiant, aucune préoccupation
4	Confiant, incertitude mineure
3	Acceptable, quelques réserves
2	Mal à l'aise, préoccupations significatives
1	Fortement en désaccord, ne doit pas s'engager

Si quelqu'un montre un 1 ou un 2, il dispose de 60 secondes pour expliquer sa préoccupation. Cela révèle souvent un risque que l'équipe devrait noter même si l'estimation ne change pas, comme une dépendance envers une autre équipe ou un morceau de code hérité qui pourrait résister aux changements. Cela prend 15 secondes par story quand la confiance est élevée et n'ajoute du temps que lorsqu'il y a une préoccupation qui vaut la peine d'être entendue. C'est un filet de sécurité à faible coût contre le désaccord silencieux.

Assembler le tout: une liste de vérification de facilitation

Les désaccords pendant le planning poker ne sont pas un signe de dysfonctionnement. C'est le mécanisme par lequel votre équipe construit une compréhension partagée. L'objectif n'est pas d'éliminer le désaccord. C'est d'avoir un moyen structuré d'extraire les informations que le désaccord contient et de les transformer en estimations meilleures et en meilleurs résultats de sprint. Pour une vue plus large des approches d'estimation au-delà du planning poker, consultez notre guide des techniques d'estimation agile.