Mais qui est donc le Product Owner ?

Mais qui est donc le Product Owner ? Véri­table lien de l’équipe Scrum, il joue un rôle essen­tiel dans l’émer­gence du projet. Aujour­d’hui, nous passons au crible ses fonc­tions, sa place dans l’équipe de travail et les outils dont il dispose.

Au sein d’une équipe Scrum, le Product Owner fait le lien entre la partie métier et la partie tech­nique du projet. Cette défi­ni­tion, bien qu’exacte, reste vague et n’ap­porte pas beau­coup d’in­for­ma­tions, chose à laquelle nous allons tenter de remé­dier.

Le Product Owner : un lien entre deux mondes

Comme dit précé­dem­ment, le Product Owner est le lien entre le client et l’équipe. C’est donc lui qui, au sein de cette dernière, porte la vision du produit. Il est l’in­ter­lo­cu­teur privi­lé­gié des utili­sa­teurs. Il devra être très dispo­nible, aussi bien pour les utili­sa­teurs que pour l’équipe. Ses compé­tences ne se limitent toute­fois pas au domaine métier puisqu’il parti­cipe acti­ve­ment au sprint et plus parti­cu­liè­re­ment à la mise en place des tests. Il favo­rise égale­ment la dyna­mique de l’équipe en lui four­nis­sant une recon­nais­sance à chaque fin de sprint lors de la présen­ta­tion du produit au client.

Un membre de l’équipe à part entière

Bien que sa présence perma­nente auprès de l’équipe ne soit pas indis­pen­sable, plus celle-ci est impor­tante, plus cela est béné­fique. Sa dispo­ni­bi­lité doit être maxi­male tout au long du projet. S’il ne décide pas de l’or­ga­ni­sa­tion de l’équipe, il est respon­sable de l’éta­blis­se­ment des Users Stories et de leur prio­ri­sa­tion. Il devra réétu­dier régu­liè­re­ment la prio­ri­sa­tion afin de la faire corres­pondre au mieux aux attentes du client et à la vélo­cité de l’équipe, itéra­tion après itéra­tion. S’il doit être ouvert au feed­back du client comme aux remarques de l’équipe lors des rétros­pec­tives, c’est tout de même à lui qu’ap­par­tient la déci­sion finale.

Les outils du Product Owner

Une des grandes respon­sa­bi­li­tés du Product Owner est donc la prio­ri­sa­tion des Users Stories. C’est égale­ment un des sujets les plus abor­dés par ceux qui débutent à ce poste. Pour défi­nir la prio­rité de chaque Users Stories, le Product Owner dispose d’un certain nombre d’ou­tils ou plus exac­te­ment d’une liste de facteurs à prendre en compte :

• L’im­por­tance de la fonc­tion­na­lité pour le client
• L’es­ti­ma­tion initiale donnée par l’équipe
• L’ex­pé­rience appor­tée
• Le facteur de risque

Grâce à ces diffé­rents facteurs, le Product Owner pourra fixer une valeur étalon qui permet­tra le clas­se­ment des diffé­rentes Users Stories par prio­rité au sein du back­log. Le back­log n’est pas défi­ni­tif et pourra être modi­fié selon l’évo­lu­tion des facteurs. Par exemple, on peut imagi­ner que le déve­lop­pe­ment d’une fonc­tion­na­lité lors d’un sprint apporte suffi­sam­ment d’ex­pé­rience à l’équipe pour lui permettre de revoir à la baisse l’es­ti­ma­tion initiale d’une autre fonc­tion­na­lité lors d’une prochaine itéra­tion.

Le profil du Product Owner

Comme le montre le compte rendu de l’Open Heart Session publié en janvier 2015 sur le blog Thiga.fr, les tâches précises d’un Product Owner dépendent beau­coup du type de projet et de la taille de l’équipe. Tous les profils iden­ti­fiés partagent tout de même certaines valeurs communes :

• une bonne connais­sance du domaine métier
• un bon esprit de synthèse
• la faculté de défi­nir tech­nique­ment un produit
• une forte capa­cité d’écoute
• la capa­cité de prendre des déci­sions et de les assu­mer

Il n’est pas forcé­ment aisé de trou­ver dans son équipe quelqu’un regrou­pant toutes ces quali­tés et faire appel à un coach ou à une forma­tion est souvent néces­saire. Il n’est pas rare de voir des Busi­ness analysts se tour­ner vers le rôle de Product Owner.