Le Product Owner : un rôle clé

De William Rogazy dans Méthodes et Organisation

25 fév 2018

Le Product Owner (PO), littéralement en français « propriétaire du produit », est un des rôles clés de la méthodologie agile SCRUM. Il fait partie de l’équipe projet et sa responsabilité est de définir le Produit Maximisé Viable dans le temps et le budget du projet.

Rôles de l’équipe Scrum (source : scrum.org H.Doshi)

 

Le Produit Maximisé Viable

Dans la méthodologie agile, le fonctionnement par itération pousse le PO à réaliser des choix fonctionnels, en priorisant le développement d’une fonctionnalité au détriment d’une autre. Afin de réaliser ce choix, le PO se base sur 4 caractéristiques (V.R.A.C.) :

  • Valeur pour les utilisateurs ;
  • Réduction des risques ;
  • Apprentissage, grâce au feedback obtenu sur une expérimentation ;
  • Coût, déduit de la taille des éléments.

L’objectif est de faire grandir en valeur le plus possible le produit d’incrémentation au fur à mesure des itérations, tout en contrôlant qu’à la fin du temps et du budget impartis au projet, le produit soit viable. C’est l’objectif du Produit Maximisé Viable.

 

Comment préparer les fonctionnalités ?

Le Product Backlog (PB)

Le Product Backlog correspond à la liste des éléments constitutifs du produit restant à développer tel que l’on l’imagine à la fin de la version de travail. Cette liste n’est pas définitive et doit être modifiée en fonction des feedbacks reçus par les utilisateurs. Ces changements concrétisent le lien entre les fonctionnalités mises en place et les besoins des utilisateurs.

Cette liste peut comporter différents niveaux de granularité au sein des fonctionnalités décrites :

  • Les « Theme » correspondent aux besoins principaux du projet, ils sont la raison d’exister du projet,
  • Les « Epics », ce sont les éléments constitutifs des « themes » . Elles sont les grandes directives fonctionnelles.
  • Puis on trouve les « Features », ce niveau n’est présent que sur les projets de grande envergure.
  • Enfin l’unité de développement reste la « User Story » (US).
Granularité de Product Backlog.

Chaque niveau est valorisé par le PO, c’est-à-dire que le PO donne une valeur numérique définissant la valeur de l’entité pour l’utilisateur. Ces valeurs n’ont pas d’unité mais permettent de comparer les entités d’un même niveau sur le plan de l’utilité.

Au sein du PB, tout n’est pas détaillé à un instant « t ». Au fur à mesure des itérations, le PO détaille les « epics » et les « features » en US. Ainsi une « epic » de valeur 100, peut se découper en 2 « features » de valeurs respectives 30 et 70, et la première peut se découper en 3 US de valeurs 15, 10 et 5.

Idéalement, si l’on estime la valeur des « epics », la somme des valeurs des US qui en découlent donne la valeur de l’épique. Mais il est acceptable que suite à un test utilisateur, une valeur donnée soit augmentée ou réduite afin d’être ajustée au besoin de l’utilisateur. C’est là un des leviers de l’agilité de la méthode.

 

Les « User Stories » (US)

Il s’agit de l’entité de développement. Elle se structure sous cette forme :

En tant que [Utilisateur concerné]
Je veux [fonctionnalité]
Afin de [besoin, bénéfice].

Lors de la préparation des US, le PO doit les rédiger, mais penser aussi aux critères d’acceptabilité. Ces derniers correspondent aux points qui seront vérifiés lors de la démonstration, afin de valider l’US. Ils donnent le détail suffisant aux développeurs pour que la fonctionnalité réponde à l’attente du PO et aux besoins des Utilisateurs. Lors de la planification de sprint, ils seront discutés, et précisés par l’équipe.

Au moment où une US est acceptée dans le sprint, elle est caractérisée par deux nombres :

  • Sa valeur : qualifiée par le PO, c’est ce qui représente son utilité
  • Un nombre de points d’effort : qualifié par les développeurs, c’est une estimation du temps à passer pour la réalisation.

 

S’appuyer sur des experts externes à l’équipe

L’équipe s’appuie sur des experts qui interviennent en tant que ressources. Ils ne font pas partie de l’équipe et ne participent pas dans l’amélioration de la méthode mais demeurent indispensables au développement du projet. Parmi ces personnes, on peut compter sur :

  • Les experts Techniques :

Ce sont des acteurs avec des attentes souvent non fonctionnelles du projet, qui peuvent appuyer le PO sur des choix techniques.

  • Les experts Métier :

Leur fonction est de fournir toutes les données métier ainsi que les méthodes d’utilisation de l’outil, nécessaires à la bonne mise en place des fonctionnalités.

  • Les experts Communication :

Ce sont les personnes qui vont vendre l’outil auprès des utilisateurs. Souvent impliquées en fin de projet, elles aident le PO dans le lancement de l’outil.

  • Les sponsors :

Tout au long du projet, ils suivent l’avancement mais se doivent de rester en retrait sur les choix effectués.

 

Avoir un temps d’avance et s’adapter

Alors que les développeurs travaillent sur le sprint en cours, le PO travaille quant à lui sur la suite. Afin de préparer la planification du sprint suivant, il doit écrire et prioriser des US. Mais cette priorisation ne sera définitive qu’à la fin de la planification.

En effet, lors de la Démonstration, des US peuvent ne pas être validées et être ainsi reportées sur le sprint suivant. De même lors de la planification, avec le coût estimé par les développeurs pour une US, le PO peut décider de repousser ou avancer le développement de l’US. C’est à ce moment précis que se joue l’Agilité d’un projet. Plus le PO est capable d’adapter sa planification au retour de l’équipe, plus le fonctionnement est agile. Dans le cas contraire, il ne s’agit que d’un développement par lots.

Parfois une US, même si elle a été travaillée et qu’elle est prête à être développée, doit être abandonnée, jetée, ou mise de côté. Il ne s’agit pas de contre-productivité que de faire cela mais de lucidité sur la valeur de l’idée.

 

Le suivi des indicateurs

Comme nous l’avons vu, le PO est responsable de la concrétisation du Produit Maximisé Viable dans le temps et le budget du projet. Afin de réussir sa tâche qui lui est incombée, il lui faut suivre son avancement et connaitre s’il y a des adaptations à effectuer. Cela peut impacter la priorisation des US mais aussi le fonctionnement de l’équipe.

Afin de suivre ses indicateurs, il est important de connaitre certaines valeurs clés :

  • Le nombre de sprint : N (calculé à partir du budget, de la durée des sprints et de la date de livraison souhaitée)
  • La valeur globale du Product Backlog V
  • L’effort global du Back Log E

On peut alors suivre si à la fin d’un sprint n sur N sprints, il faut qu’ait été développé au moins de valeur.

On parle aussi de vélocité d’un projet (en : effort  réalisé au cours du sprint n)

Cette vélocité, c’est l’effort moyen réalisé par sprint. Idéalement la courbe de la vélocité et celle de la valeur embarquée doivent se suivre et tendre vers l’aboutissement de l’effort et de la valeur dans le temps et le nombre de sprints imparti au projet.

Ainsi le PO peut suivre à chaque fois la courbe de l’effort réalisé, celle de la valeur réalisée et tous autres graphiques qui permettraient à l’équipe de mieux suivre l’évolution du projet et de réagir au plus vite à toute dérive du projet.

 

Être la pointe de flèche d’une équipe afin d’atteindre sa cible

Pour résumer toutes ces fonctions, je prendrai la comparaison avec la flèche de l’archer. La cible est le Produit Maximisé Viable, dirigé par la pointe qui est le PO, toute la flèche (l’équipe) doit être orientée vers la cible. Il est de la responsabilité du PO de mettre en œuvre une vraie notion d’équipe projet, afin de gagner en cohésion et en efficacité. Le SCRUM Master est quant à lui les plumes de la flèche, à lui de faire en sorte que l’équipe ne dérive pas. Mais cela sera le sujet d’un prochain article.

 

Commentaire

un + = 5

iMDEO recrute !

REJOIGNEZ-NOUS

A la recherche de nouveaux talents (développeurs web et mobile, chefs de projet,...)

Voir les annonces