C’est le propriétaire du produit et l’un des trois rôles présent dans Scrum. Le Product Owner est la clé de voûte du projet. Il fait le lien entre les objectifs de l’entreprise, les besoins des utilisateurs et l’équipe qui réalise le projet. Il représente aussi les clients et les utilisateurs qui vont exploiter ce dernier après la livraison.
Quelles sont les responsabilités principales du Product Owner ?
Il connaît le projet dans sa globalité. Par conséquent, c’est lui qui porte la vision du produit. Il est nécessaire que cette vision soit partagée efficacement avec le client et l’équipe de développement. Avec le premier pour s’assurer que le projet va dans la bonne direction métier, avec la seconde afin que les incréments du produit répondent bien aux demandes du métier.
Propriétaire du product backlog, le Product owner analyse, priorise et formalise les besoins du client. Le product backlog est l’un des artefacts de Scrum où l’on retrouve la liste de toutes les exigences fonctionnelles du produit. Ces exigences sont découpées en fonctionnalités, elles-mêmes rédigées sous forme de users stories qui sont assorties de critères d’acceptance. Ces users stories sont priorisées par ordre d’importance, c’est à dire que les premières fonctionnalités qui seront développées sont mises au début du backlog produit. Cet ordre est défini en fonction des besoins du client. L’approche du Product owner est donc ROIste.
Enfin, il valide l’incrément produit lors de chaque sprint. Pour cela, les critères d’acceptance indiquent à l’équipe de développement ce que l’on attend avec exactitude d’une user story. Car, si celles-ci ne sont pas respectées, le Product owner est en droit de la refuser.
Quelles sont les missions du Product owner ?
Il cadre le projet tout au long de son déroulement :
– Pour commencer, le Product owner connaît les besoins métier du client, c’est pour cette raison qu’il en est le représentant auprès de l’équipe de développement.
– Il pilote le produit par la valeur, c’est à dire qu’il priorise les fonctionnalités les plus importantes pour le client. Toutefois, il doit tenir compte des enjeux techniques ou organisationnels de l’équipe.
– Il est responsable de la constitution du backlog de produit sous forme de user stories priorisées. Ces dernières sont rédigées de façon fonctionnelles, et non techniques, pour assurer une bonne compréhension de la part de tous les acteurs du projet.
– Il rédige de la documentation au fil de l’avancement du projet, et vérifie que celle-ci soit produite du côté de l’équipe de développement.
Il gère la qualité du produit lors des itérations :
– Il propose les objectifs de sprint (sprint goal) et doit respecter la charge de travail de l’équipe de développement, estimée à l’aide du planning poker, en fonction de la capacité de sa production.
– Il affine et met à jour le backlog de produit tout au long du projet. Pour cela, la démonstration de sprint est déterminante car il y reçoit les feedback du client. Alors, la liste des users stories est re-priorisée, voire de nouvelles users stories sont ajoutées ou supprimées.
– Il fait partie de l’équipe Scrum, et à ce titre participe aux rituels : planification de sprint, daily meeting, revue de sprint et rétrospective de sprint. Notons, qu’il n’est pas obligatoirement présent lors du daily meeting. Mais il est utile qu’un Product owner s’y rende une à deux fois par semaine pour connaître l’état d’avancement de l’équipe de développement.
– Il doit être disponible pour répondre aux questions de l’équipe. Un Product owner fréquemment absent ralentit l’équipe dans sa production d’incrément.
Il garantit la qualité des users stories :
– Le Product owner définit et vérifie que les critères d’acceptance contenus dans les users stories soient bien respectées par l’équipe de développement.
– Ses interventions sont fondamentales lors de deux cérémonies Scrum : la planification de sprint (sprint planning) et la revue de sprint (sprint review). Pendant la planification de sprint, il définit l’objectif de l’itération et présente les users-stories à l’équipe de développement. Quant à la revue de sprint, c’est une cérémonie qui lui permet de montrer l’incrément au client. La présentation de l’incrément est destinée à susciter des réactions et à favoriser la collaboration.
– Enfin, iI valide les users stories réalisées si celles-ci répondent avec exactitude aux critères d’acceptance. Mais il peut aussi les refuser.
D’autres points importants concernant le rôle du Product owner
– Ce n’est pas un rôle de management. Il n’y a aucun manager au sein d’une équipe Scrum.
– Le Product Backlog est un artefact qui relève de la responsabilité du Product Owner. Tandis que, que le sprint backlog relève de la responsabilité de l’équipe de développement. Toutes modifications sur ces artefacts ne peuvent avoir lieu qu’avec l’accord de celui qui en est le responsable.
– Le rôle de Product Owner n’est pas cumulable avec celui de Scrum master et il ne peut être tenu par un comité de personne. Le non respect de ces critères entraînerait des conflits et les prises de décisions seraient ralenties.
– A des intervalles réguliers, il participe avec l’équipe à définir l’objectif du sprint. Celui-ci peut être fonctionnel, technique ou organisationnel. Scrum priorise une expression fonctionnelle car elle est la plus facile à comprendre par tous. On peut estimer qu’un objectif technique peut être transformé en objectif fonctionnel.
– Il arrive de façon exceptionnelle qu’un Product Owner soit amené à annuler un Sprint si l’objectif de celui-ci devient obsolète. Alors, on démarre une nouvelle planification de sprint. Mais le Product Owner est le seul à pouvoir prendre cette décision.
Lien vers la certification Product owner.
Article mis à jour le 03/04/2020
