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 équipes Scrum 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.

Focus sur le Backlog de produit

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

Le Backlog de produit doit être visible, clair et compréhensible. 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. 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 de ce qui reste à faire, comparé à ce qui a été réalisé. Décrire clairement les éléments conduit également à mieux comprendre...

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 :

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. 

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 de développement, 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.

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, est un artefact de transparence.