Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Le Product Owner
  3. Le métier de Product Owner
Extrait - Le Product Owner Maîtriser son rôle et ses missions (2e édition)
Extraits du livre
Le Product Owner Maîtriser son rôle et ses missions (2e édition) Revenir à la page d'achat du livre

Le métier de Product Owner

Focus sur le rôle de Product Owner

Le guide Scrum nous indique que le Product Owner a pour responsabilité de maximiser la valeur du produit résultant du travail de l’équipe de développement, que la façon de jouer ce rôle peut varier grandement selon les organisations, les Scrum Teams et les individus et qu’il est le seul responsable de la gestion du Backlog de produit.

Cette fonction est incomparable avec celle de chef de projet. Il existe très peu de points communs entre ces deux fonctions alors qu’il y a plusieurs points divergents. 

1. Le Product Owner n’est pas un chef de projet

Selon la définition du dictionnaire Larousse, un chef est une « personne qui commande, qui exerce une autorité, une influence déterminante ». D’après Wikipédia, le chef de projet est une personne qui est responsable de la planification, de l’approvisionnement et de l’exécution d’un projet en fonction d’un périmètre établi et d’une date de début et de fin définie.

Il existe de nombreuses différences entre le chef et le Product Owner, au niveau du périmètre de la mission, du cœur même de la mission, du focus ou du centre d’intérêt et enfin des moyens employés pour accomplir la mission.

a. La responsabilité du Product Owner

Alors qu’un chef de projet est responsable d’un projet et généralement de sa planification, la responsabilité du Product Owner porte sur le produit, et plus précisément sur la valeur que peut atteindre celui-ci en fonction du travail réalisé par l’équipe de développement.

Le chef de projet est responsable de l’équipe, des moyens dont les personnes disposent, de l’organisation interpersonnelle, de la planification de la délégation et du suivi d’activité ou des tâches.

Le Product Owner n’est pas responsable de l’équipe, mais il doit faire au mieux pour qu’ensemble ils puissent obtenir un produit de la plus grande valeur possible. Le Product Owner est le représentant des utilisateurs, des clients ou des consommateurs, et doit orienter au mieux les développements du produit pour satisfaire leurs besoins. ...

Focus sur le Backlog de produit

Cet outil de management visuel permet en un coup d’œil de voir clairement ce sur quoi les Developers doivent prochainement travailler, mais également tout ce qui reste potentiellement à faire.

Le Backlog de produit est un élément essentiel de Scrum. C’est avec cet outil que le Product Owner organise la conception et la réalisation du produit et donne de la visibilité sur l’organisation et l’avancement des travaux à tous les acteurs de l’organisation qui sont concernés par le produit.

images/p2-2.png

Le Backlog de produit doit être visible, clair et compréhensible.

Si la Scrum Team doit produire des diaporamas pour expliquer où elle en est lors de chaque revue de Sprint, il faut inspecter la clarté du Backlog de produit. Le Product Owner peut utiliser n’importe quelle solution à condition que l’information reste facilement et rapidement accessible. Utiliser un tableur ou une application qui ne serait visible que lorsque le Product Owner le décide n’est pas une bonne approche. De la même manière, dresser une liste d’éléments incompréhensibles ou incohérents n’a qu’une très faible valeur ajoutée.

L’illustration ci-dessus est un parfait contre-exemple, car indiquer qu’il reste à faire les éléments 6 à 12 n’apporte qu’une information à faible valeur ajoutée. Rien ne précise ce que sont ces éléments ni s’ils sont plus complexes à produire que ne l’ont été les précédents. Indiquer que les éléments 1 à 3 sont finis peut apporter une information utile, mais il est alors préférable d’inspecter l’incrément de produit et principalement l’usage réel qui est fait de ce produit. De la même manière, mentionner ce qui est en cours a peu d’intérêt, car il vaut mieux inspecter le ou les Backlogs de Sprint.

En revanche, rendre visibles les détails concernant chaque élément du Backlog de produit offre une information de meilleure qualité. Par exemple, connaître la charge, l’effort ou la complexité de chaque élément permet de se faire une meilleure idée...

Les éléments du Backlog de produit

Lorsqu’on fait référence aux éléments du Backlog de produit, il s’agit bien souvent d’User Stories, mais rien dans Scrum n’impose ce formalisme. Le guide Scrum 2017 décrivait le Backlog de produit comme étant le conteneur de toutes les descriptions d’activités nécessaires au fonctionnement, à la maintenance, à la modification ou à l’amélioration du produit :

Le Backlog de produit liste toutes les fonctionnalités, les fonctions, les exigences, les améliorations et les corrections qui constituent des modifications à apporter au produit dans les versions futures. Les items du Backlog de produit ont les attributs d’une description, d’un ordre, d’une estimation et d’une valeur. Les items du Backlog de produit incluent souvent des descriptions de test qui prouveront leur complétude lorsqu’ils sont « Finis ».

Guide Scrum 2017

Les items du Backlog de produit, c’est-à-dire les éléments, ne respecteront pas forcément le formalisme d’écriture propre aux User Stories. Ce formalisme, que nous détaillerons ultérieurement, est cependant une bonne pratique que de nombreux Product Owners utilisent lorsqu’ils souhaitent décrire des éléments suffisamment fins. Au fur à mesure de l’évolution de Scrum, cette notion d’attributs, permettant de mieux ordonner les éléments au sein du Backlog de produit, prend de plus en plus de valeur. 

Les éléments du Product Backlog qui sont susceptibles d’être réalisés dans un seul Sprint par la Scrum Team sont considérés comme prêts à être traités en Sprint Planning. Ils acquièrent généralement ce degré de transparence après avoir été affinés. L’affinement du Backlog de produit consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s’agit d’une activité continue visant à ajouter des détails, tels qu’une description, un ordre et une taille.

Guide...

Focus sur la définition de « Fini »

Cet engagement de Scrum est aussi important pour le Product Owner que le Backlog de produit. Celui-ci recense ce qu’il convient de faire et dans quel ordre en fonction des objectifs liés au produit. La notion de « Fini » contribue, elle, à fixer des règles sur la manière de le faire en fonction des contraintes liées au produit.

La définition de « Fini », réalisée par l’équipe, traduit un ensemble d’exigences non fonctionnelles et de critères d’acceptation. C’est ce référentiel qui détermine la qualité du produit. La définition de « Fini » porte sur les critères d’acceptation du produit, mais également sur sa qualité technique : sa robustesse, sa performance, sa sécurité, sa lisibilité ou sa maintenabilité. 

Il est donc important que la définition de « Fini » soit claire et compréhensible par tout le monde, y compris par des personnes qui n’ont aucune connaissance technique.

La notion de « Fini » permet d’assurer la transparence.

1. Définition du guide Scrum

La version 2020 du guide Scrum présente une description de la définition de « Fini » allégée et sa définition a été transformée en un engagement, associé à l’incrément (troisième artefact de Scrum). Plusieurs informations ont été regroupées dans cette redéfinition alors qu’elles étaient éparses dans la version 2017. Dans cette version, la définition de « Fini » constitue le dernier chapitre, mais de nombreuses références y sont faites tout au long du document, et le fait de les lire ensemble permet d’avoir une meilleure compréhension de la notion de « Fini » et de son importance.

Dans la description de la transparence :

Ceux qui exécutent le travail et ceux qui inspectent l’incrément résultant doivent partager une définition commune de « Fini ».

Guide Scrum 2017

Les Developers...

Focus sur la transparence

La transparence est un des trois piliers de Scrum que le Product Owner peut utiliser pour mieux accomplir sa mission : maximiser la valeur. La transparence consiste à rendre les éléments d’information clairs et compréhensibles par tous.

Bien utilisée, elle présente un bénéfice concret pour le Product Owner, lui permettant une plus grande marge de manœuvre et un respect accru de la part des parties prenantes vis-à-vis de ses décisions sur le produit.

La notion de « Fini », décrite dans les pages qui précèdent, a longtemps été considérée comme un artefact de transparence. C’est aujourd’hui un engagement lié à l’incrément.

1. Définition

Le guide Scrum décrit la transparence dès la page 6, mais la partie la plus intéressante se trouve en introduction de la définition de « Fini ».

Scrum repose sur la transparence. Les décisions pour optimiser la valeur et contrôler le risque sont prises en se basant sur l’état perçu des artefacts (NdA : le Backlog de produit est un artefact). Dans la mesure où la transparence est complète, ces décisions ont une base solide. Dans la mesure où les artefacts ne sont pas totalement transparents, ces décisions peuvent être faussées, la valeur moindre et le risque accru.

Guide Scrum 2017

La prise de décision repose sur la nature des informations dont disposent les décideurs et sur la manière dont ces derniers perçoivent et interprètent les informations. Plus les informations sont claires et transparentes, plus les chances que tous les acteurs partagent la même analyse s’accroissent. Certes, le Product Owner est théoriquement la seule personne à même de prendre des décisions concernant le produit, mais il n’est pas le seul décideur de l’organisation et est soumis à diverses pressions. 

2. Les vertus de la transparence

Plus le Backlog de produit et la définition de « Fini » sont transparents, c’est-à-dire clairs et compréhensibles par tous, plus les décisions ou les recommandations du Product Owner feront...