Le Product Owner est une des pièces maitresses de la gestion de projet en mode Agile Scrum. Plus qu’une méthodologie, Scrum est un état d’esprit avec pour principal objectif l’optimisation de l’alignement sur les besoins.

Pour bien comprendre la valeur ajoutée d’un Product Owner (PO) dans un projet de développement logiciel, il faut avant tout bien comprendre toutes les facettes de son rôle.

Le rôle du Product Owner

Porter et transmettre la vision du client

Le Product Owner est le représentant permanent du client au sein de l’équipe, ou plus exactement des utilisateurs du produit à concevoir. Bien évidemment, il peut être le client lui-même, dans le cas d’une squad hybride par exemple. Il représente la voix du client et transmet les objectifs du produit à l’équipe de développement à chaque itération.

Apporter de la transparence au client

Il donne de la visibilité au client et l’informe à chacune des étapes de l’avancée du produit : échéances, contraintes budgétaires, contraintes techniques et fonctionnelles, solutions envisagées et implications, pour éviter l’effet tunnel.

Créer et maintenir le Backlog d’un produit

Une partie essentielle de son rôle est de gérer le Backlog. Le Backlog n’est pas un cahier des charges gravé dans le marbre. Il vit et évolue en même temps que le projet mais surtout, il doit être le reflet des besoins du client sans toutefois préjuger de l’investissement technique nécessaire associé.

Ecrire des Users Stories

Le Product Owner doit savoir écrire de bonnes Users Stories ‘objectif’ et leur attribuer une valeur métier ‘bénéfice valeur’ en fonction des attentes du marché, du client et du ROI attendu. Il doit aussi s’assurer de leur bonne compréhension tout en laissant le soin à l’équipe de développement d’estimer l’effort à fournir pour chacune d’elle. C’est en fonction de ces informations qu’il proposera des itérations ou encore ‘sprints’ pour la réalisation de ces user stories afin que les utilisateurs puissent les tester et les valider.

Prioriser le Backlog

Le Product Owner doit savoir extraire dans la liste des Users Stories celles qui apportent le plus de valeur ajoutée au produit afin de les développer et les tester en priorité pour intégrer les feedbacks importants pour le produit le plus rapidement possible.

Il doit aussi distinguer les user stories qui sont dépendantes du développement d’autres Users Stories et bien calculer l’ordonnancement du développement des tâches.

Optimiser le retour sur investissement (ROI)

Le Product Owner est responsable du ROI du produit développé et de sa qualité. Sa responsabilité est engagée dans les décisions économiques liées à la gestion d’un sprint, au niveau du produit. Le budget, le temps et la qualité peuvent être ajustés en fonction des besoins et des spécificités de chaque Product Backlog.

En outre, il est de la responsabilité du PO de s’assurer du respect des délais, d’informer en cas de retard ou de difficultés et de déclarer qu’une User Story peut passer au statut ‘terminé’.

En résumé

Contrairement au chef de projet, le PO est garant

• De la valeur du produit, pas du produit réalisé
• Du Backlog, pas des tâches techniques et opérationnelles
• De la vision du produit, pas du rapport hiérarchique avec l’équipe
• De l’orchestration des sprints, pas du contenu de la livraison

Les qualités d’un Product Owner

Le PO n’intervient pas dans le « comment » de la réalisation, il est avant tout l’arbitre des priorités. Sa valeur ajoutée réside dans sa capacité à optimiser le travail de l’équipe et à maximiser la valeur du produit en fonction du besoin. Il n’est pas forcément critique qu’il ait un profil technique en revanche, les qualités suivantes sont très importantes :

• Etre totalement engagé : c’est clé pour le succès du projet en mode agile dans une équipe en mode auto-organisée
• Avoir de bonnes compétences en communication pour répondre aux sollicitations, dialoguer et interagir avec tous les publics et pour s’adapter à toutes les situations
• Etre exigeant et encourager le rythme soutenu des sprints pour forcer les utilisateurs à s’exprimer sur les éléments livrés et éventuellement réorienter un développement qui n’est plus d’actualité ou pas satisfaisant en l’état
• Savoir gérer les conflits et d’en tirer les enseignements pour trouver la solution
• Savoir dire non et être en capacité de justifier pour quelles raisons tel ou tel feedback ou demande de modification ne sera pas développé. C’est beaucoup plus difficile que d’ajouter les fonctionnalités sans chercher à comprendre au risque de participer au retard du projet

Bénéfices attendus

• Optimiser l’efficacité des comités de pilotage notamment grâce à la préparation
• Apporter de la clarté à l’équipe de développement et augmenter les chances de succès du produit.
• Impliquer le client de bout en bout pour qu’il soit au courant des obstacles, difficultés et du fonctionnement de son produit
• Proposer des solutions constructives et productives
• Limiter le gaspillage d’énergie, de temps et d’argent en éliminant  les nombreuses fonctionnalités demandées « au cas où », sans réelle justification ni d’usage précis
• Minimiser le risque de prise de retard du projet en priorisant le Backlog et en validant toutes les étapes avec le client
• Coller au plus près aux demandes du client et faire en sorte que le produit réponde de manière optimale aux besoins