Décoder le jargon du Product Owner

jargon product owner

Aujourd’hui j’écris un article destiné à toutes les personnes qui travaillent de près ou de loin avec un product owner et qui veulent comprendre son jargon.

Dans ce 1er post, je vous donne 10 mots importants du jargon du product owner. (Voir la partie 2 ici).

J’espère que ces quelques définitions simplifiées vous donneront les clés pour comprendre et communiquer avec un Product Owner.

Pourquoi apprendre le jargon d’un product owner ?

  • Un product owner vient de rejoindre votre boite depuis peu ?
  • Vous devez collaborer avec lui /elle  ?
  • Vous n’avez pas de background technique ?

Si vous participez à une réunion où un product owner prend la parole, il y a fort à parier que vous ne comprenez absolument rien à son jargon.

Vous entendez des termes tels que “Scrum, Kanban, Sprint, Backlog Grooming, Story points, User stories, Sprint Retrospective, Sprint Planning… “.

Même en étant totalement bilingue en anglais, vous vous sentez perdu.

Ce jargon est en fait celui qui est utilisé quotidiennement par une équipe de développeurs web.

Au final, rien de grave, maintenant qu’il y a un product owner pour gérer les développeurs, c’est son job de vous décoder ce charabia.

Oui mais…

Ce n’est parce qu’un Product Owner est capable de parler votre langage que vous ne devez pas être capable de parler (un peu) le sien.

En comprenant son langage, vous allez faciliter grandement votre collaboration et vos projets risquent d’avancer beaucoup plus vite. 

Mieux ! En décodant son jargon, vous allez maitrisez, vous aussi, la partie technique d‘un projet.

Voici donc la définition des 10 termes les plus populaires du jargon d’un product owner et de son équipe.

1. LA MÉTHODE AGILE :

Parmi tout le jargon de base du product owner, la méthode agile est LE terme le plus employé.

Pour faire simple, la méthode agile est une pratique permettant de piloter des projets techniques de la manière la moins figée possible au niveau contractuel (entre le client/utilisateur et les développeurs).

Concrètement, la méthode agile permet de pouvoir réaliser un projet technique en ayant à l’esprit que des changements sur le planning initial peuvent intervenir à tout moment.

Les changements peuvent être:

  • Des nouvelles demandes clients
  • Des bugs
  • Toutes autres découvertes ou obstacles majeurs réalisés lors de la conception du produit.

Le terme “agile” désigne une souplesse dans les prises de décisions. Il encourage un dialogue constant entre les différents partis impliqués dans le projet afin de le faire évoluer dans le bons sens et minimiser les erreurs.

Pour résumer, la méthode agile permet de s’adapter en temps (presque) réel aux aléas de la vie d’un projet.

A RETENIR:
Ils existent plusieurs variantes de la méthodologie agile. Chacune à son fonctionnement propre mais toutes respectent le même but :

L’optimisation de la gestion de projet via un dialogue ouvert entre les acteurs du projet et une capacité de réactivité quasi immédiate.

Ci-dessous, nous vous présentons les 2 méthodologies agiles les plus populaires en entreprise: Le scrum et le Kanban.

2. LE SCRUM :

Le “Scrum” est certainement la méthode agile la plus populaire du moment. C’est celle la plus employée dans les entreprises tech. Si vous devez en connaître une seule, c’est celle-ci que je vous conseille de comprendre.

Le scrum est une méthode qui découpe un projet en séquence de temps (appelées sprint).
Pendant chacune de ces séquences, l’équipe de développement doit réaliser une fonctionnalité du produit qui doit être en capacité d’être livré et testé par l’utilisateur final.

La complexité de la fonctionnalité est défini en fonction du temps imparti pour la réaliser (effort).

A RETENIR:
Le scrum fonctionne à la manière d’un kit de lego.
Plutôt que de tout construire en une fois, l’équipe technique découpe le projet en mini tâches de développement. Chaque tâche correspond à une fonctionnalité à réaliser en un temps défini.

Par exemple:
Si vous avez une application mobile à réaliser. Plutôt que que de rédiger toutes les fonctionnalités sur un seul cahier des charges, la méthodologie scrum vous permet de décomposer votre projet en plusieurs tâches.

  1. Visuel de la page d’accueil
  2. Page de création de compte
  3. Page de connexion
  4. etc..

3. LE KANBAN :

Autre méthodologie agile orientée suivi de projet, la méthode Kanban permet de s’émanciper de toute limite de temps pour effectuer des tâches. C’est l’inverse de la méthode Scrum.

L’intérêt premier est de se concentrer sur la qualité du travail fourni plutôt que sur la quantité (productivité).
Une tâche est terminée seulement quand le contrôle qualité a validé entièrement le résultat final.

La philosophie de la méthode kanban est de contrôler visuellement le flux de travail grâce à la mise en place d’un tableau sur lequel on suit l’évolution de chaque tâche. 

Kanban signifie « étiquette » en japonais. 

Sur ces étiquettes (ou post-it), on indique une tâche à réaliser que l’on ajoute au tableau. Chaque colonne du tableau représente une étape (à faire, ouvert, en cours, en test, terminé). 

Chaque tâche évolue jusqu’à ce qu’elle soit achevée. À chaque étape de franchie, on change la tâche de colonne

Une des particularité également de la méthode Kanban est qu’elle permet d’avoir une vision plus global d’un projet.

En effet, les tâches d’un projet Kanban peuvent être multi-métiers.

Par exemple, on peut utiliser la méthodologie Kanban pour visualiser l’ensemble des tâches Marketing, commerciales, techniques etc… d’un projet.
C’est plus souple que la méthode Scrum qui se concentre uniquement sur les tâches de développement.

4. RECIT UTILISATEUR / USER STORY :

L’un est le terme français (récit utilisateur), l’autre est le terme anglais (user story).

Mais c’est quoi un récit utilisateur au juste ?
Il s’agit de la description d’une fonctionnalité produit rédigé par le P.O à destination de son équipe technique.
Le récit utilisateur décrit une tâche qui se place du point de vue de l’utilisateur final du produit

Exemple de récit utilisateur:

“En tant que visiteur du site découvrirlapolynesie.fr qui arrive sur la page d’accueil, je peux accéder aux promotions du mois en haut de page.”

Au delà de cette description générale, le récit utilisateur est toujours accompagné d’informations plus détaillées.
Ces informations complémentaires sont appelées “critères d’acceptation”.

Les critères d’acceptation permettent aux développeurs de comprendre les contours technique de la fonctionnalité:
Ex: expérience utilisateur, limites, ce que l’utilisateur peut faire et ne peut pas faire…

Par ailleurs, pour des fonctionnalités logicielles qui nécessitent un changement graphique (nouvelle image, nouveau design…), le récit utilisateur est accompagné d’images en pièces jointes élaborées par le UX designer de l’équipe.  

Bon à savoir:
Le logiciel le plus populaire pour rédiger des récits utilisateurs s’appelle Jira. Sur cet outil, les récits utilisateurs se prénomment les issues.

5. L’EPIC  :

Une épic (parfois traduit en épopée) est un groupement de récits utilisateurs qui visent la même fonctionnalité produit.
Pour comprendre la fonction d’une epic, il suffit de s’imaginer que vous avez plusieurs documents papiers qui ont le même thème (exemple: page d’accueil).
Plutôt que de les éparpiller un peu partout sur votre bureau, vous décidez de les classer dans un même dossier regroupant ce thème.

En somme une épic est un dossier à thème regroupant tous les récits utilisateurs qui évoquent ce thème.

 Exemple:

  • Epic thème “Nouvelle page d’accueil” incluant les 3 récits utilisateurs suivants
    • Rechercher des promotions sur la page d’accueil 
    • Créer un compte sur la page d’accueil 
    • Contacter le service client sur la page d’accueil 

En créant une épic, le P.O peut regrouper les récits utilisateurs d’une même fonctionnalité produit sous un même thème.

L’avantage principale de l’epic est d’éviter de créer des récits utilisateurs trop grands et trop longs à réaliser.

6. LE BACKLOG : 

Le backlog est l’ensemble des tâches (récits utilisateurs) du P.O rassemblé dans une seule liste.

Dans les logiciels en ligne tels que Jira ou Gitlab, chaque nouveau récit utilisateur rédigé par le P.O vient s’ajouter automatiquement au backlog.

Le backlog doit être entretenu quotidiennement par le P.O afin de s’assurer que chaque tâche soit bien priorisée.

7. LE BACKLOG GROOMING :

Le backlog grooming ou parfois appelé simplement grooming est la cérémonie durant laquelle le P.O présente à son équipe les nouveaux récits utilisateurs de son backlog.

Cette échange permet de valider la faisabilité technique de chaque récit utilisateur. A la fin de chaque validation, l’équipe doit estimer l’effort de réalisation de chaque récit utilisateur.

Attention, en anglais le terme « grooming » à plusieurs significations qui n’ont rien à voir avec le sens donné ici.

Le backlog grooming est une étape essentielle dans le fonctionnement d’un projet.
Cette cérémonie permet au P.O de pouvoir établir un planning de développement pour les tâches futures à accomplir.

BON À SAVOIR:
Le backlog grooming demande la présence de toute l’équipe du P.O. Chaque membre doit être en mesure de comprendre le détails des récits utilisateurs afin d’estimer la charge de travail précisément.
Le backlog grooming est avant tout un échange entre le P.O et son équipe.
Cet échange permet de finaliser des détails techniques manquants.

8. LES STORY POINTS :

Le story point est un système de calcul permettant d’estimer l’effort demandé pour la réalisation d’un récit utilisateur.

L’une des particularité de la méthode Scrum est d’estimer une tâche en fonction de l’effort à fournir plutôt qu’en durée de temps. 
Cette idée est souvent perçue comme étant à contre courant de la logique d’estimation d’autres secteurs d’activités.
Par exemple:

Si vous demandez un devis à votre garagiste, il va vous facturer un prix en fonction du temps de main d’oeuvre nécessaire à la réparation.

Le problème c’est qu’en mécanique comme en informatique l’estimation en durée s’avère bien souvent inexacte car cela dépend de l’expertise homme.

En effet, un développeur Junior ou une jeune recrue ne va pas résoudre un problème logiciel aussi vite qu’un développeur expérimenté.
Un développeur plus senior connaît très bien le produit et à déjà résolu le même type de problème dans le passé.

Evidemment, afin d’optimiser le planning, le PO peut confier la tâche au développeur senior.
Cependant la logique du “Story point” est avant tout de définir l’effort nécessaire à la réalisation de la tâche peu importe l’expérience du développeur.

Un article apparu dans le blog de Xebia donne une super analogie pour mieux comprendre ce qu’est un Story point.

En résumé, l’effort correspond à la distance à parcourir (200 mètres) et est toujours fixe.
A l’inverse, la durée de parcours est aléatoire en fonction du coureur.
Imaginez Usain Bolt ! Il va certainement prendre moins de temps que vous pour terminer la course.

En bref, telle la distance de la course à parcourir, l’effort est toujours fixe.

Mais pourquoi parle t-on de points ?

Maintenant que vous compris le terme d’effort, il s’agit de comprendre comment le mesurer.

Malheureusement, contrairement à la durée, il n’existe pas d’unité de mesure universelle pour estimer un effort.

Pour cela, la méthode la plus simple est d’attribuer un nombre de points à l’effort.

La logique est la suivante, plus l’effort est faible, plus le nombre de point est petit.

BON À SAVOIR:
Afin de donner un cadre au nombre de points et fixer des limites. La majorité des entreprises ont adopté une échelle de point basée sur la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, …).

Encore une fois si vous souhaitez en savoir plus sur le sujet, nous vous conseillons de lire l’article de blog du cabinet Xebia. Ce post vous explique en détails tous les avantages de cette méthode. 

9. LE SPRINT :

Le sprint (traduit en itération) définit une séquence de temps fixe durant laquelle un groupe de récits d’utilisateurs doit être réalisés.

En majorité, la durée moyenne d’un sprint est de 2 semaines. Dans certains cas, un sprint peut durer 3 ou 4 semaines (cela dépend des règles internes de l’équipe produit).

BON À SAVOIR:
Quelque soit sa durée, un sprint commence en général un lundi matin et se termine un vendredi soir.

10. LE SPRINT PLANNING :

Le sprint planning est l’action de planifier les tâches (récits utilisateurs) à réaliser dans le ou les prochains sprints par l’équipe de développeurs.

Afin de pouvoir planifier un sprint, il est nécessaire que le product owner dispose d’un backlog composé de récits utilisateurs déjà estimés (groomés).

Cas pratique:

  • Imaginons que le Sprint de Martin qui est product owner dans une startup FinTech à une durée de 2 semaines.
  • L’équipe de Martin est composée de 5 développeurs
  • Martin travaille avec les mêmes développeurs depuis des années. Il connaît leur cadence de travail et est capable à l’avance d’estimer leur vélocité.
  • Par exemple, pour faire simple, Martin sait que chaque développeur est capable de réaliser 15 points par sprint.
    Grâce à cette estimation, Martin peut calculer que la vélocité d’un sprint est de 75 points (5X15).
  • Dans cet exemple, pour planifier son sprint, Martin devra choisir un nombre de Users stories dans son backlog ne dépassant pas 75 points au total. Cette estimation lui permet d’avoir un planning de développement réaliste.

Evidemment cet exemple est très simplifié. En réalité, dans le planning d’un sprint il faut aussi prendre en compte d’autres facteurs externes:

  • L’effort nécessaire pour terminer les tâches restantes du sprint précédent (il y en toujours)
  • Des jours fériés qui tombent au milieu d’un sprint
  • L’absence de certains membres de son équipe pendant le sprint (congé, absence maladie…) 
  • Il est aussi prudent de garder une marge de 20% de temps libre qui sera alloué à différents problèmes surprises (bugs logiciels…). Ces bugs sont généralement à régler en urgence pendant le sprint.

A RETENIR:

Le sprint planning est un exercice très délicat.
Il nécessite de bien évaluer l’effort à réaliser dans un temps imparti et s’appuie sur 2 choses essentielles:
– Des estimations de récits utilisateurs qui sont réalistes.
– Une grande connaissance de ses collaborateurs et du produit

Un sprint planning mal planifié peut avoir de lourdes conséquences sur les objectifs fixés.

Le jargon, c’est simple au final !

Non, je plaisante…

Le jargon du product owner est plutôt intimidant et fait d’anglicismes techniques.  

L’essor des techniques agiles dans le monde de l’entreprise ont fait cohabiter 2 mondes qui ne se cotoyaient pas dans le passé.

Il est normal que chacun des deux mondes ait son propre jargon qui reste encore opaque pour l’autre.

Au final il ne s’agit pas de devenir un expert.  C’est une question de temps. Plus vous collaborez les uns avec les autres dans vos projets numériques, plus les automatismes vont s’opérer.
A terme, vous mixerez vos langages et vous comprendrez le jargon de chacun.

Au cas où vous bloquez encore sur un mot de jargon, n’hésitez pas à demander aussitôt au product owner. Ne restez pas dans l’ignorance !

Il n’y a rien de mal à poser une question. Sachez que le product owner est conscient de son rôle dans l’entreprise et de l’incompréhension qu’il suscite.

C’est aussi son job de vous aider et de vous expliquer les choses.



Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *