Planning Poker , généralement considéré comme l’outil standard pour effectuer des estimations pour les projets Agile, est un outil souvent mal compris et mal utilisé. Au cours de mes années de coaching d’équipes Agiles, j’ai vu des équipes gérer ce processus de manières très différentes, dont certaines n’ont pas réussi à appliquer correctement l’outil sans le savoir. J’ai personnellement observé de nombreuses variantes du processus de Planning Poker, certaines efficaces et d’autres dysfonctionnelles. Je vais en partager quelques-uns avec vous pour vous aider à améliorer l’efficacité du processus d’estimation pour vos équipes Agile.
Avant de partager les trucs et astuces, je voudrais d’abord clarifier l’objectif d’estimation du travail en utilisant Planning Poker comme outil. Avec ces objectifs à l’esprit, nous pouvons nous concentrer sur des comportements appropriés qui amélioreront notre capacité à atteindre ces objectifs.
Objectif #1 – Établir approximativement la portée du travail qui permet de mesurer la vitesse de l’équipe, ce qui permet la prévision (par exemple, la planification des versions).
Objectif #2 – Promouvoir la discussion sur la portée des travaux requis pour répondre aux critères d’acceptation des articles du carnet de produits.
Astuce #1 – Évitez de convertir les heures de travail en points d’histoire
Les équipes qui sont nouvelles dans le développement Agile essaient souvent de tout quantifier, ce qui est attendu étant donné que les personnes à l’esprit technique ont une tendance naturelle à donner un sens aux choses par la logique. Dans ce contexte, l’utilisation d’unités d’heures de travail est un concept beaucoup plus facile à comprendre que la taille relative du travail qui tient compte de l’effet, de la complexité et du niveau de compréhension du travail. Les équipes qui établissent une formule (c’est-à-dire 8 heures par point de user story) ne comprennent généralement pas pleinement la valeur des estimations relatives, ce qui consiste à acquérir une compréhension de haut niveau du travail avec un effort minimal. Par conséquent, je vous recommande fortement d’encadrer de nouvelles équipes Agile pour éviter cette erreur; il sera difficile et probablement stressant pour les membres de l’équipe technique d’apprendre à estimer le travail avec une mesure sans unité telle qu’un Story Point, il leur faudra donc probablement un acte de foi pour l’expérimenter. Insistez sur le fait que cette méthode d’estimation permet à l’équipe de dériver une estimation au niveau de l’équipe, PAS une estimation individuelle, ce qui profitera à l’ÉQUIPE à long terme.
Conseil #2 – Évitez de penser en groupe en étant discipliné dans le processus d’estimation
Certaines équipes que j’ai coachées ont tendance à devenir très laxistes avec le processus de Planning Poker parce que cela ressemble à un jeu plutôt qu’à une approche sérieuse pour faire un travail significatif, peut-être parce que le fait d’avoir des cartes en main désarme automatiquement les gens? C’est difficile à savoir avec certitude. Bien qu’il soit bien de garder les choses assez décontractées, il est important de gérer le processus et de s’assurer que l’équipe passe son temps à bon escient. Un écueil majeur à éviter est basé sur le concept de «pensée de groupe», qui est le phénomène où les individus acceptent passivement les opinions d’un groupe plus large afin d’éviter les conflits, même si leur opinion diffère de celle de la majorité du groupe.
Dans la plupart des cas, il est difficile de détecter les pensées de groupe, mais dans le contexte de Planning Poker, il est plus facile de voir cela se produire, surtout si les membres de l’équipe sont d’accord avec les estimations des autres membres de l’équipe sans aucune discussion. Il s’agit d’un comportement négatif qui enlève l’efficacité du processus. Encouragez tous les membres de l’équipe à s’exprimer et à défendre leurs positions; ne modifiez pas automatiquement votre estimation simplement parce que le membre senior de l’équipe a une estimation très différente. Insistez sur le fait que chaque individu apporte une perspective importante à l’équipe, c’est pourquoi on leur donne la possibilité de donner leur voix.
Astuce #3 – Évitez la personnalisation excessive des cartes Planning Poker
Certaines équipes avec lesquelles j’ai travaillé ont tendance à personnaliser les cartes de poker utilisées pour Planning Poker, c’est-à-dire à sélectionner des cartes spécifiques qu’elles jugent judicieuses d’utiliser pour un sprint spécifique. Ma recommandation est que vous choisissez une série, soit Fibonacci (1, 2, 3, 5, 8, 13, 21), soit Fibonacci modifié (1, 2, 3, 5, 8, 13, 20) et respectez-la. Ne changez PAS la série à moins qu’il n’y ait une bonne raison de faire appel à la consultation du Coach Agile. Certaines équipes ajoutent le « ? » carte pour permettre aux membres de l’équipe de soulever le besoin d’acquérir plus d’informations. Je suggère d’utiliser cette carte avec parcimonie en raison d’une mauvaise utilisation potentielle.
Une mauvaise utilisation des cartes peut devenir un gros problème pour l’équipe si elle continue de se produire. Certaines équipes ont tendance à abuser du « ? » carte en utilisant cette carte de manière excessive; cela peut conduire à des discussions prolongées et inutiles concernant les détails de la User Story qui peuvent réduire l’efficacité de l’équipe et ralentir le processus. Certaines équipes n’utilisent que 1 à 13, 13 étant la taille maximale pour une histoire qui peut tenir dans un seul sprint. Bien que cela puisse sembler être un moyen efficace de garantir un vote rapide, cela peut conduire à des estimations inexactes en raison de l’absence d’un moyen d’indiquer que l’histoire est trop volumineuse pour être remplie en un sprint! L’équipe peut choisir un 13 même si l’histoire est trop grande, simplement parce qu’il n’y a pas d’autre option. Cela peut sembler trivial en surface, mais avec le temps,
Conseil #4 – Assurez-vous que les bonnes personnes participent au processus de Planning Poker
Certaines des équipes que j’ai coachées ressentent le besoin de réduire le nombre de personnes qui participent au processus de planification car elles estiment que seules les personnes les plus expérimentées comprennent suffisamment le produit ou le système pour être en mesure de fournir une estimation précise. Ce type de réflexion est fondamentalement imparfait, étant donné que le processus d’estimation relative n’a pas pour but de dériver une estimation précise. Lorsque les équipes limitent le nombre de participants à un sous-ensemble de l’équipe entière, vous perdez essentiellement l’expérience et l’expertise des membres qui ne sont pas engagés dans le processus. Cela peut entraîner beaucoup plus de tort que ce à quoi on pourrait s’attendre, des estimations inexactes à la dégradation du moral de l’équipe. Mon conseil: impliquez toute l’équipe (toutes les personnes qui font le travail) lors de l’estimation du travail pour l’équipe!
Conseil #5 – Évitez le fluage de la valeur de point lors de l’étalonnage
Lorsqu’une équipe Agile a travaillé ensemble pendant quelques sprints et a obtenu un succès visible, certaines équipes sont encouragées à «produire plus de travail», ce qui est un anti-modèle qui sort du cadre de cet article. La chose clé à noter ici est que même les équipes Agile les meilleures et les plus expérimentées peuvent rencontrer un phénomène connu sous le nom de «fluage de la valeur en points», qui est une condition où les estimations des User Stories augmentent lentement avec le temps. Par exemple, une User Story qui était autrefois une histoire en 5 points, est lentement devenue une 8 pour une raison quelconque. Cela peut se produire de manière naturelle et mystérieuse, et conduira généralement à une perception que l’équipe fait plus de travail et / ou offre plus de valeur au fil du temps; bien que cela puisse sembler positif, le risque réside dans des attentes plus élevées qui conduisent à une pression accrue de la part des dirigeants, ce qui est un cercle vicieux.
La technique que je recommande pour atténuer le risque de cette condition est l’étalonnage régulier des User Stories. Il existe probablement de nombreuses approches différentes pour y parvenir, mais une méthode est la triangulation des histoires en prenant des histoires déjà terminées (c’est-à-dire 2 points et 8 points) et en la comparant à l’histoire actuelle et active de 5 points, et en évaluant si cette histoire active est en fait une histoire en 5 points. De plus, localisez une autre histoire à 5 points d’un sprint précédent et comparez-la à l’histoire active pour déterminer si elles correspondent en termes d’effort / complexité.
Je pense que le processus d’estimation de Planning Poker est une compétence «facile à apprendre, mais difficile à maîtriser», tout comme beaucoup d’autres techniques de développement Agile. En recherchant les écueils potentiels, vous pourrez aider vos équipes à tirer le meilleur parti de cet outil.
