Comment jouer au Planning Poker ?

Comment jouer au Planning Poker ?
Comment jouer au Planning Poker ?

Le planning poker est un outil utilisé en agile. La raison de son utilité est qu'il peut aider l'équipe à décider du nombre de points à attribuer à une histoire ou à une tâche particulière. Cela permet de faciliter les discussions interminables.

La méthode décrite ci-dessous vous montre comment utiliser le Planning Poker pour faire des estimations. Cependant, il est important de comprendre que chaque équipe diffère légèrement des autres. Vous pouvez essayer d'adapter les règles et les processus pour trouver la solution qui convient le mieux à votre équipe.

Comment fonctionne le planning poker ?

Lorsque votre équipe joue au Planning Poker, vous vous appuyez sur l'expertise des membres de l'équipe concernés, qui peuvent donner leur avis personnel sur les user stories.

Cette technique peut aider l'équipe à se rapprocher de la charge de travail ou de la complexité de la tâche et à s'assurer que tout le monde est d'accord.

Si quelqu'un dans le groupe choisit une carte différente, alors parfois, il faut absolument un débat ou même une dispute jusqu'à ce que l'équipe parvienne à un consensus sur sa mise en œuvre.

Les conditions préalables :

Pour jouer au Planning Poker, vous devez remplir les conditions suivantes :

  • L'équipe Scrum doit comprendre le fonctionnement du Planning Poker.
  • Un groupe de développeurs doit être d'accord à l'avance avec l'histoire décrite par le propriétaire du produit.
  • Planifier une partie de poker
  • S'ils estiment la charge de travail ou la complexité relative, l'équipe doit accepter
  • Comprendre ce qu'est l'histoire de base convenue et combien de points sont marqués.

Dans le cas de sondages ou de discussions partagées, le Product Owner peut être contacté

Comment jouer :

Distribuez des cartes :
Assurez-vous que chaque membre de l'équipe dispose d'un jeu de cartes.

Ces cartes ont généralement des valeurs numériques, et leur signification est la suivante :
0 : Une valeur de zéro signifie que la story peut être complétée en n'effectuant aucune opération. Elle est principalement utilisée lorsque le déploiement est suspendu.

0,5 : Ce n'est pas zéro, mais presque un morceau de gâteau que les aveugles peuvent faire.

1 : Il s'agit d'une histoire courte, sans complexité ni effort.

2 : Le double du sens de 1.

3 : Un peu plus que 2.

5 : C'est une carte intéressante. Il faut de l'intelligence et des efforts pour que cette histoire se réalise. Largement utilisée lorsque l'histoire devient sérieuse.

8 : Beaucoup plus que 5, mais encore contrôlable.

13 : Ce chiffre montre que l'histoire de l'utilisateur est à la pointe, devenant trop compliquée pour être considérée comme une seule histoire. Envisagez de diviser l'histoire.

20 : Cette carte exprime principalement un certain désespoir de la part des membres de l'équipe. En tant qu'équipe, vous devriez envisager de diviser l'histoire.

40 : Dans une large mesure, ces cartes expriment simplement le désespoir des membres de l'équipe. En tant qu'équipe, vous devriez envisager de diviser l'histoire.

100 : Dans une large mesure, ces cartes expriment simplement le désespoir des membres de l'équipe. En tant qu'équipe, vous devriez envisager de diviser l'histoire.

? : Une carte en forme de point d'interrogation apparaît, et le développeur ne sait pas comment estimer l'histoire.

☕️ : La planification d'un sprint peut être épuisante. Cette carte montre que le membre de l'équipe demande une pause brutale.

Acceptez de vous référer à la story :

Surtout lorsque vous jouez au Planning Poker pour la première fois. Il est utile de se souvenir de l'histoire ou de la tâche que l'équipe a récemment réalisée et de se mettre d'accord sur sa valeur.

Cette story sera utilisée comme histoire de référence pour l'estimation.

Veillez à ne pas choisir une histoire trop petite ou trop grande, car cette histoire de référence doit durer plus longtemps que le sprint suivant afin d'obtenir un graphique de burn-down et une vélocité significatifs tout au long du projet.

Vous pouvez également ignorer la définition d'une histoire et vous fier entièrement à l'intuition de votre équipe. L'effet est meilleur qu'à première vue.

Histoire par histoire :

L'équipe peut maintenant ouvrir la première user story, de préférence sur un grand écran ou sur un autocollant que tout le monde peut voir.

Ensuite, assurez-vous que tout le monde comprend ce qui doit être fait dans cette histoire d'utilisateur. Cette étape est très importante et chaque membre de l'équipe doit utiliser un petit signe (comme "pouce levé") pour confirmer.

Ensuite, posez à l'équipe la deuxième question, à savoir si tout le monde sait comment traiter cette histoire. (Ne parlez pas beaucoup et ne discutez pas à ce stade, sauf si au moins un développeur a du mal à trouver une solution ou n'est pas sûr).

Estimations :

Maintenant, chaque membre de l'équipe de développement (que ce soit le propriétaire du produit ou le Scrum Master) choisit en silence une carte qui n'est pas visible par les autres membres de l'équipe.

Lorsque tout le monde a préparé la carte, vous la retournez et la montrez en même temps à l'équipe.

Les résultats suivants sont alors possibles :

...Lorsque tout le monde choisit la même carte :

Inscrivez le point convenu dans l'histoire et passez à l'histoire suivante.

...Lorsque différentes valeurs de cartes sont affichées ( ? ou "pause café")

C'est la partie intéressante. C'est le moment du débat. Ne sautez jamais vraiment cette partie, choisissez simplement une moyenne...

La base pour préparer le débat :

Choisissez la personne la plus qualifiée avec le moins de chiffres.

Choisir la personne la plus qualifiée avec le plus de chiffres

L'équipe ne sélectionne que 2 personnes, même si le chiffre le plus élevé ou le plus bas a été affiché plusieurs fois.

Maintenant, les développeurs avec les chiffres les plus élevés expliquent l'idée derrière la carte sélectionnée. Aucune discussion n'est autorisée à ce stade.

Plus tard, les développeurs représentant t

Plus tard, les développeurs représentant la valeur la plus basse expliquent les idées derrière leurs choix.

L'ensemble du groupe comprend les idées de chacun et peut les comparer silencieusement aux siennes.

Sans autre discussion, passez au tour d'estimation suivant. Affecté par l'explication initiale, chacun peut changer d'avis, choisir une autre carte, puis revenir au tour précédent.

Continuez cette itération jusqu'à ce que tout le monde soit d'accord sur le même nombre.

...Lorsqu'un " ?" est affiché

Laissez cette personne exprimer ses préoccupations. Et essayez de la clarifier.

...Lorsque la carte "pause café" est affichée

En équipe, décidez si et quand prendre une pause-café.

Quelle que soit la décision de l'équipe, considérez que l'un de vos coéquipiers est fatigué et qu'il est heureux de faire une pause pour recentrer son attention.

Ce qu'il faut faire et ce qu'il ne faut pas faire :

Ne travaillez pas avec des marges :

Les équipes inexpérimentées ou instables se relâchent sur la tâche pour compenser l'incertitude de cette histoire ou d'autres en estimant un nombre plus élevé que nécessaire.

Ne faites jamais cela ! Il est normal de faire de mauvaises estimations de temps en temps. Vous devez également tenir compte du fait que vous pouvez créer d'autres histoires moins complexes que vous ne le pensez.

L'objectif derrière le story point est d'atteindre une vitesse fiable et constante. Ne collectionnez pas les points.

Ne comparez pas avec d'autres équipes :

Les estimations et les story points ne peuvent pas être comparés avec d'autres équipes. Chaque équipe convient de sa propre histoire de référence et peut utiliser une gamme différente de cartes.

Réflexion après l'impression :

Afin d'améliorer continuellement votre précision et votre fiabilité, pensez à revoir vos histoires les plus sous-estimées ou surestimées. Et faites des ajustements dans le prochain plan.

Acceptez les erreurs de vos coéquipiers :

Tout le monde n'est pas un expert dans tous les domaines. Instaurez une culture de respect de la discussion tout en valorisant et en débattant.

C'est la pire des choses quand quelqu'un n'a pas le cœur à donner son avis. Vous risquez de bloquer des contributions importantes à l'avenir.

Impliquez les élèves du primaire dans le débat :

Créez une certaine diversité lors de l'élection des débatteurs. Donnez aux jeunes développeurs une voix pour comprendre ce qui est important pour eux et leurs progrès en matière de développement personnel.

Lorsque vous pouvez contribuer à combler des lacunes dans les connaissances sur un sujet particulier, aidez-les en leur proposant des séances de programmation en binôme. En termes d'amélioration continue des compétences de l'équipe, c'est un repas gratuit.

Arrêtez-vous lorsque vous estimez qu'il y a suffisamment de points réalisables dans le sprint :

Calculez votre vitesse prévisionnelle avant de commencer à estimer. De cette façon, vous pouvez vous arrêter après un laps de temps raisonnable ou envoyer un signal à votre responsable de produit pour qu'il fournisse plus d'histoires lorsqu'elle est nettement inférieure.

Afin de préparer un backlog de sprint équilibré, il est recommandé que le PO soit le membre passif de la salle lorsque vous jouez au planning poker. De cette façon, le Product Owner peut comprendre intuitivement quelles histoires sont concernées et lesquelles ne le sont pas.

Préparer le backlog pendant le sprint suivant est une technique pratique pour fournir un nombre plus précis d'éléments de backlog. Les améliorations du backlog ne peuvent être effectuées que par une partie de l'équipe ou par un seul développeur mature du propriétaire du produit.

Ne modifiez pas l'estimation pendant le sprint :

Que l'estimation du story point soit incorrecte lorsque vous traitez l'histoire, ne changez jamais d'avis pendant le sprint.

Au contraire, notez-la et présentez-la lors de la prochaine rétrospective afin que l'équipe puisse apprendre et s'améliorer.

Qu’attendez-vous ? Utilisez Chpokify pour une séance de planning poker !

Chpokify | Planning Poker | Essential Sprint Plannin...
Chpokify is a digital poker card game designed to help agile and scrum development teams effectively set their sprint goals through collaborative p...

Subscribe to Chpokify community Articles and Blog Posts | Chpokify

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]
Subscribe