Décoder le jargon du product owner – (Part 2)

Dans la lignée de mon premier post, je vous aide à décoder de nouveaux mots de jargon du product owner.

Cette fois ci,  je vous donne 5 définitions simplifiées de concepts Scrum utilisés par le product owner dans son quotidien.

L’idée est d’aider les aspirants product owners ou toutes autres personnes qui collaborent avec des POs à comprendre son langage.

Au programme dans ce post :

• Le burndown chart
• Definition of done
• Le planning poker
• 3 amigos
• La rétrospective

1. BURNDOWN CHART :

Pour faire court, le burndown chart est un outil qui permet de mesurer les performances de l’équipe au cours d’un sprint.

Représenté sous forme d’un graphique simple, il indique l’état d’avancement dans la réalisation des tâches au jour le jour.

Comment lire un burndown chart ? 

• Sur l’axe vertical, vous indiquez le nombre de points total à réaliser au cours du sprint. Ici j’ai mis 45 points.
  Ce nombre de points est obtenu lors du sprint planning 
• Sur l’axe horizontal, vous indiquez le nombre de jour travaillez pendant la durée du votre sprint. Ici j’ai mis 10 jours.
  Ecrivez une lettre pour indiquer le jour de la semaine.
• Enfin, dans l’exemple ci-dessous je trace une ligne bleue correspondant à l’avancement idéal du début jusqu’à la fin du sprint.

Cette vue me permet d’avoir une référence pour se baser sur le travail à accomplir au jour le jour.

Ainsi, si on suit l’avancement idéal de l’exemple ci-dessous, voici le nombre de points restants à faire à la fin du jour 4

Évidemment cette représentation linéaire ne correspond jamais à la réalité.

Ainsi au cours de votre sprint, vous devez tracer au jour le jour une deuxième ligne rouge pour indiquer l’état d’avancement réel.

En comparant le tracé de la ligne rouge et le tracé de la ligne bleue, vous pouvez vous situer par rapport à vos objectifs.

Le burndown chart est un indicateur visuel qui permet de s’évaluer quotidiennement et de réagir avant qu’il ne soit trop tard en cas de problème.
Retenez ce mot de jargon, le product owner l’utilise tous les jours.

Bon à savoir :

• Vous pouvez réaliser votre burndown chart sur un tableau blanc et le mettre à jour tous les jours avec votre équipe lors du daily.
• Vous pouvez également utiliser des outils en ligne pour faire des burndown charts.
• Ou dernier recours, certains outils de gestion de projet agiles tels que Jira vous propose la fonctionnalité. L’avantage c’est que votre burndown chart est mis à jour automatiquement en temps réel avec l’avancement des issues dans votre sprint.

2. DEFINITION OF DONE (DOD) :

Le Definition of done (ou la définition du fini) est un barème fixé par le product owner et son équipe pour déterminer si une user story peut être considérée comme complété ou pas.

Ce concept n’est pas facile à expliquer car sa définition est relative selon les équipes avec lesquelles vous travaillez.

Voici les 4 critères définis avec mon équipe actuelle pour s’assurer qu’une User Story est implémentée.

Comme vous pouvez le voir sur la capture ci-dessous, chaque étape est représentée dans un board kanban.

1. Développement terminé (colonne 2) + Optionnel selon les Stories : La documentation à été mise à jour
2. Revue de code effectuée (colonne 3)
3. Les tests définis dans la User Story (acceptance criteria) ont été réalisés et passés avec succès. (colonne 4)
4. Développement prêt à être livré dans un environnement stable – User story terminée (colonne 5)
   

Ces étapes sont propres à la Definition of Done de mon équipe. C’est un classique.

Pourtant, il est tout à fait possible que certaines équipes aient des étapes supplémentaires pour passer une user story en Done.

Tout dépend de l’entreprise, de l’équipe et du type de produit.

A quoi ça sert ?

Le DOD (comme on dit dans le jargon) est un accord entre les membres de l’équipe et le product owner pour éviter des désaccords et des débats sur la validation d’une user story.

En clair, cela évite les mauvaises surprises.

Par exemple :

• Si 100% des critères d’acceptation ne sont pas respectées, le user story ne pourra pas être défini comme Done. Personne ne peut en débattre.

Cet accord est décidé en amont d’un sprint et reste stable pendant une longue période.

On ne change pas le Definition of Done à chaque sprint.

Cependant, le DOD peut évoluer au fur et à mesure de la maturité du produit pour adapter le process en fonction de la complexité du travail à réaliser.

Le concept de DOD est à mettre également en relation avec le concept de Definition of Ready.

Je reviendrai sur ce concept plus tard

Bon à savoir :

C’est l’équipe qui est responsable de sa définition, pas le product owner.

En général si une équipe dispose d’un ingénieur test, c’est à lui de valider que la user story répond à 100%  des critères “Definition of done”

3. PLANNING POKER

Le planning poker est une expression qui désigne autrement la cérémonie du backlog grooming dans la méthodologie Scrum.

En réalité si vous avez compris le grooming, c’est exactement la même chose.
Si vous n’avez aucune idée de ce que l’on appelle le grooming, lisez d’abord ceci avant de lire la suite.

Pourquoi on parle de poker ?

On parle de poker car au moment d’estimer la user story, les participants disposent de cartes en main.
Evidemment les valeurs de ces cartes ne sont pas les mêmes que celles d’un jeu de cartes de Poker traditionnel.

Chaque carte correspond à une valeur de points effort relative à la suite de Fibonacci.
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144.

En général comme je l’ai expliqué dans le post sur le backlog grooming, on ne va pas au delà de la valeur 21 (c’est déjà trop pour une seule user story).

Au moment d’estimer, chaque participant retourne les cartes en même temps et montre sa valeur point effort.

En cas de différence entre les votes, le facilitateur (product owner) demande aux acteurs qui ont le chiffrage le plus extrême d’expliquer leur logique d’estimation.

Une fois la discussion terminée, on recommence le vote et en cas de différences, on prend en compte la moyenne arithmétique de chaque vote pour estimer la valeur finale.

4. THREE AMIGOS

Les 3 amigos est encore une fois une cérémonie utilisée dans la méthodologie scrum.

Elle n’est pas obligatoire et je connais peu de product owner qui l’utilise.

Cependant elle mérite d’être démystifiée afin de vous aider à la comprendre et l’implémenter dans votre équipe.

Pourquoi ce nom ?

Si vous comprenez un minimum l’espagnol, 3 amigos signifie “Les 3 amis”.
Au passage, c’est le seul mot à consonance hispanique dans le jargon du product owner.

Les 3 amis dont on parle ici sont le product owner, un développeur et un testeur.

Contrairement aux autres cérémonies scrum, les 3 amigos n’est pas une cérémonie avec un objectif précis.

En général, les 3 amis se réunissent pour résoudre un problème en profondeur qui nécessite une vision 360 de l’aspect technique du produit.

Voici 2 cas pratiques : 

1. Définir une user story à 3 avant de la présenter lors de la séance de grooming.
   Cela permet d’affiner une user story et de compléter la dimension test quand le product owner requiert une expertise supplémentaire pour définir les critères d’acceptance.
   
   
2. Priorisation des bugs
   Dans un backlog il y a 2 types de bugs. Ceux que l’on va corriger et ceux que l’on ne corrigera pas.
   Plutôt que de laisser traîner des bugs qui vont végéter des mois dans le backlog, il vaut mieux les fermer.

La séance des 3 amigos peut permettre une revue des bugs et de se mettre d’accord sur les priorités.

Au final, la cérémonie des 3 amigos est une point entre experts pour fluidifier la préparation du planning et le backlog produit.

Personnellement, j’ai une séance 3 amigos toutes les semaines pendant une heure, durant laquelle je discute des nouveaux bugs ouverts par l’équipe de test.

5. SPRINT RETROSPECTIVE :

Un sprint rétrospective est une cérémonie durant laquelle le product owner et son équipe débriefent à propos du déroulement du sprint qui vient de se terminer.

Le sprint rétrospective se déroule généralement le dernier jour du sprint (le vendredi).

Son but est avant tout de récolter le point de vue de chaque membre de l’équipe sans faire de jugement pour comprendre deux points essentiels:

• “ Qu’est-ce qui à bien fonctionné pendant le sprint ? “
• “ Qu’est-ce qui aurait pu être mieux fait ? ”

L’objectif affiché est avant tout de trouver les actions qui puissent améliorer la performance de l’équipe lors du prochain sprint,
La rétrospective est aussi un excellent exercice de team-building car elle permet à chacun de se dire les choses ouvertement et de mieux apprendre à travailler ensemble.

Au terme du Sprint rétrospective, l’animateur de la réunion doit rassembler les actions identifiées à réaliser lors du prochain sprint qui doivent permettre d’accroître la productivité de l’équipe.

Un sprint rétrospective est généralement une réunion où l’atmosphère doit être détendue afin d’éviter les conflits.
Pour cela les rétrospectives peuvent se dérouler à l’extérieur des bureaux pour sortir du cadre de travail. 

Le maître de cérémonie fait parfois appel à l’utilisation de  jeux de rôles afin d’apporter une atmosphère plus bon enfant et faciliter la communication

Bon à savoir:

Le product owner est rarement l’animateur d’un sprint retrospective car étant un membre de l’équipe à part entière, sa participation à la cérémonie en tant qu’acteur est cruciale.

Généralement, une personne extérieure à l’équipe appelée le Scrum Master est en charge d’animer le Sprint rétrospective.
Celui ci libère le Product Owner de cette tâche et lui laisse la liberté de partager son vécu sur le sprint écoulé.

A RETENIR 

Encore une fois, nous rencontrons un jargon lourdement emprunt d’anglicismes et même d’hispanismes.

Si vous n’êtes pas product owner, j’espère avoir fait assez simple pour que vous puissiez comprendre la base.

Dans le cas où vous voulez devenir product owner, connaissez ces termes et approfondissez les une fois que vous êtes en poste.

Si ce genre de post sur le jargon du produt owner vous a plu, dites-le dans les commentaires.
Il y a encore matière à vous expliquer de nouveaux termes.