Plusieurs product owner dans une équipe ?

Est-il possible d’avoir plusieurs product owner dans une équipe Scrum ? Et si vous êtes dans ce cas, comment optimiser cette pratiques ? Nous allons voir cela dans cet article.

Vous pouvez regarder la vidéo de La Minute Agile sur le sujet réalisée avec l’excellente Amina Bourguiba :

Plusieurs product owner dans une équipe Scrum ?

Le Scrum Guide dit NON !

Alors si nous nous arrêtons sur le Scrum Guide, il est assez formel sur le sujet :

Une équipe Scrum comprend un Product Owner, une équipe de développement (Development Team) et un Scrum Master.

scrum guide fr

Et si on est agile ?

Donc si nous faisons du scrum by the book, cette pratique est donc clairement interdit par le Scrum. Cependant, en agile, nous disons régulièrement qu’il faut s’adapter au contexte et être capable d’avoir une certaine flexibilité.

Contexte fréquent avec plusieurs product owner

En effet dans certaines structures, l’agilité n’est pas encore un pilier de sa culture. Et il n’est pas rare de voir des « dits » product owner qui ne sont pas liés à un produit mais à une expertise particulière sur de gros produits.

Et ce type d’organisation complexifie considérablement le travail des équipes qui tentent tant bien que mal à mettre du Scrum en place. Doit-on dire à ces équipes d’abandonner Scrum ou les aider à faire face à ce contexte ? Après tout, tout un travail de réorganisation peut se faire en parallèle pour améliorer ce contexte complexe.

Partant dans l’idée d’aider les équipes, nous allons voir quelques astuces non négligeable pour améliorer ce type de contexte.

Plusieurs product owner pour une équipe – nos astuces

Un product owner en interlocuteur principal

La première astuce proposée serait de voir si il n’est pas possible d’avoir un seul PO comme interlocuteur principal de l’équipe. Si celui-ci n’écrirait pas toutes les user-stories (pas au démarrage), il serait le responsable d’un backlog unique !

Et avec un peu de coaching, il serait même possible peu à peu d’amener cet interlocuteur principal à écrire en partie l’ensemble des user-stories. Ceci placerait les autres product owner en tant que parties prenantes… Et au final, on irait peu à peu vers une véritable organisation Scrum.

Pour cela, rassemblez l’ensemble des product owner et voyez avec eux, celui qui semble avoir le plus d’impact avec cette équipe et qui serait prêt à prendre ce rôle de centralisateur. Et si il n’y a pas de consensus sur le sujet, il sera toujours possible de voir avec le sponsor du projet, si il peut aider dans cette désignation.

Avoir un backlog unique

Il est essentiel d’avoir qu’un seul backlog autour du produit géré par cette équipe scrum. Il n’est pas rare que chaque product owner ait son backlog mais cela complexifie considérablement la priorisation et la standardisation des items (user-stories).

L’utilisation d’un board de maturation des user-stories pour l’ensemble des PO pourra également fortement aider à la standardisation de l’écriture des user stories. 

Priorisation entre les product owner

Afin de constituer les prochaines itérations (tout en respectant la capacité de faire de l’équipe de développement), il est recommandé que les product owner se rassemblent régulièrement pour prioriser ensemble l’ensemble de leurs éléments respectifs.

Pour cela, ils doivent tenter de définir une valeur commune pour que chacun des éléments ait une valeur claire, comparable et exploitable. Sans ce travail de priorisation en groupe, l’équipe de réalisation subira considérablement les priorisations chaotiques durant les sprint planning.