Dans le cadre de notre trajectoire de mise en place de l’Agilité à l’échelle depuis 1an, je me rend compte en tant que Scrum Master, que pour le moment les rôles de PM/PO ne sont pas correctement maîtrisés et nous avons les irritants suivants :
Les features sont créées par les PO et non pas par le PM ;
Les stories sont créées par l’équipe de DEV et non pas par les PO ;
Les PO ne font pas de revue de backlog et ne gère pas leur backlog de stories ;
Depuis le passage à l’échelle, les PO ne donnent plus d’objectif de sprint en sprint planning ;
Comment pouvons-nous revenir à de bonnes pratiques et sensibiliser les acteurs sur ces irritants.
Si j’étais un peu coquin, je diras : on a l’impression qu’en fait l’organisation est assez saine, le seul problème c’est qu’on a nommé des gens « PO » mais qui en pratiques ne servent pas à grand chose, le rôle de PO (au sens Scrum) étant assumé par le PM.
Aussi, as-tu vu nos vidéos sur les rôles PO vs PM ainsi que sur celui de Proxy PO ? Ils pourraient t’apporter des éléments de réponse, ou du moins détailler / expliciter mon paragraphe précédent.
P.S. : wow, ça fait beaucoup de vignettes de JP Lambert !!!
Les features sont créées par les PO et non pas par le PM ;
C’est vrai, les POs sont souvent plus proche du besoin, et font les features. Mais ils ne sont pas seuls, ils le font avec l’aval est le support des Epics Owner et l’accord du PM.
Sans compter que le RTE doit veiller à ce que l’on se concentre sur ce qui apporte le plus de valeur.
Les stories sont créées par l’équipe de DEV et non pas par les PO ;
Oui, si elles ont été créé en avance, elles sont revues en PI planning sinon elles sont créées durant le PI planning. Et souvent suite à cette définition le score de la feature peut être modifié;
Tout n’est que négociation.
Les PO ne font pas de revue de backlog et ne gère pas leur backlog de stories ;
Euh, ça c’est très étrange…
Depuis le passage à l’échelle, les PO ne donnent plus d’objectif de sprint en sprint planning
Il faut essayer de comprendre pourquoi. Sinon peut être que le Scrum master doit être aider, supporter par le RTE.
C’est au fond pas une question bête parce qu’il y a beaucoup de confusion chez beaucoup de gens sur le sujet.
Feature (trad: fonctionnalité) : On appelle communément une fonctionnalité d’un logiciel ou d’un produit une « feature ». C’est une implémentation, une capacité, et elle a donc déjà fait l’objet d’une définition et d’un raffinage.
(User) Story (trad: récit ?): C’est un pense bête tenant en une phrase, proposé par l’utilisateur.ice ou son .sa représentant.e (!!! le PO n’est PAS le représentant des utilisateurs !!!) et amenant l’équipe à une discussion avec le ou la dite représentante/utilisatrice. Le toute permettant à l’équipe de définir une feature potentiellement développable.
