(Ou comment le ou la Product Owner devrait choisir les éléments à développer et autres choses ayant de la valeur)

En tant que product owner, l’une de vos responsabilités est la tenue du backlog et sa priorisation. 

Ça veut dire, entre autre, prendre des décisions sur ce qui peut, ou ne peut pas, entrer dans le backlog du produit. 

Il faut savoir dire “non”… mais pas bêtement !

Avec des grandes responsabilités, viennent de grandes collaborations

Dans une équipe Scrum, avoir la responsabilité ne veut pas dire qu’on doit tout exécuter tout seul. Le bon sens devrait même nous dicter que ce n’est jamais le cas !

De plus, une équipe Scrum est auto-organisée et composée de toutes les compétences nécessaires.

De plus encore, il est de bon ton d’éviter les problèmes de capacité si l’un des rôles est absent ou indisponible. 

Et si toute l’équipe décidait, ensemble, des éléments pouvant être ajoutés au backlog produit ?

Un travail collaboratif

On s’approche beaucoup de la notion de “customer” dans XP, mais il ne me semble pas que ce soit incompatible avec Scrum, dont le Product Owner est un rôle plutôt accès sur le marketing (vous trouverez un lien en bas de page sur ce sujet).

C’est donc toute l’équipe qui pourrait décider que la demande d’un utilisateur a du sens (ou pas). 

On s’assure ainsi que toute l’équipe a compris le problème à résoudre et que ça apporte une vraie valeur aux utilisateurs. Une valeur, comprise et acceptée par tout le monde.

Les difficultés techniques émergent plus tôt, permettant de discuter d’éventuelle contre-mesures avec le client directement.

Plus de souplesse

Le jour où le Product Owner est en vacances, dans ce mode de fonctionnement l’équipe sait gérer et décider de nouveaux éléments de backlog sans avoir à l’attendre, ou sans que le ou la Product Owner n’ai à préparer le backlog pour 2 ou 3 itérations.

Bien sûr, cela implique que l’équipe passe plus de temps en réunion, avec les utilisateurs, donc, pour ne pas pénaliser la production, cela nous force à ne pas prévoir un backlog à très long terme. On se concentre sur ce qui apporte le plus de valeur pour les prochaines semaines.

L’engagement de toute l’équipe sera sûrement plus fort vis à vis du produit, qui, rappelons-le, n’est qu’un moyen pour améliorer la vie des utilisateurs. 

Je vous conseille vivement la lecture de l’article de Ron Jeffries sur “l’agile au-delà de l’agile”.

Et vous ? En tant que PO vous vous sentez un peu seul face à l’arrivée des Stories ? Avez-vous déjà eu l’idée de faire collaborer tout le monde ? 

Essayez demain ! Vous commencez par quoi ?

Voici un article de Jean-Pierre Lambert sur le rôle du marketing au sein de l’équipe Scrum que je vous conseille de lire : https://jp-lambert.me/si-le-marketing-nest-pas-au-c%C5%93ur-de-l-%C3%A9quipe-scrum-alors-vous-avez-rat%C3%A9-votre-transfo-7b4c4f9e54a0.