Le Product Owner (PO) en Scrum oscille en permanence entre deux extrêmes: le désengagement et le micro-management. Ces deux postures, apparemment opposées, produisent des dysfonctionnements similaires, car dans les deux cas l’équipe ne reçoit pas le niveau de guidance dont elle a besoin au bon moment.
Le PO fantôme
Le premier anti-pattern est celui du PO qui considère sa responsabilité comme essentiellement administrative. Il rédige les user stories, participe au Sprint Planning, puis disparaît jusqu’à la Sprint Review. Entre ces deux événements, l’équipe fonctionne en autonomie forcée plutôt qu’en autonomie choisie.
Les conséquences sont prévisibles. Les Developers prennent des décisions fonctionnelles qui auraient dû être validées par le PO. Les critères d’acceptation sont interprétés librement, ce qui génère des écarts entre ce qui est livré et ce qui était attendu. Le Scrum Guide précise que le PO est responsable de la maximisation de la valeur du produit, une responsabilité qui s’exerce au quotidien, pas uniquement lors des cérémonies.
Ce schéma s’installe souvent quand le PO cumule son rôle avec d’autres responsabilités (chef de projet, responsable métier, membre d’une autre équipe). Le temps partiel est l’ennemi du rôle de Product Owner: la disponibilité continue est une condition de succès, pas un luxe.
Le PO contrôleur
À l’autre extrémité du spectre, le PO omniprésent pose un problème différent. Il assiste à chaque Daily Scrum, challenge les estimations techniques, demande des comptes-rendus quotidiens et modifie les priorités en cours de sprint. Sous couvert d’engagement, il reproduit un schéma de management directif incompatible avec l’auto-organisation de l’équipe.
L’impact sur l’équipe est direct: les Developers cessent de prendre des initiatives, car chaque décision est remontée au PO pour validation. L’innovation et la créativité technique diminuent, car l’équipe se cantonne à exécuter exactement ce qui est spécifié. Le Product Backlog (la liste ordonnée de tout ce qui pourrait être nécessaire au produit) se transforme en spécification détaillée où le PO décrit le “comment” en plus du “quoi”, privant l’équipe de sa contribution la plus précieuse.
Le backlog révélateur
Le Product Backlog est souvent le meilleur indicateur du positionnement du PO. Un backlog surdimensionné, avec des dizaines d’items non priorisés, signale un PO qui accumule sans arbitrer. Un backlog où chaque story contient une spécification technique détaillée révèle un PO qui confond orientation fonctionnelle et prescription technique.
Un backlog sain se reconnaît à quelques caractéristiques: il ne contient pas plus de trois à quatre sprints de travail en items actifs, les éléments proches du sommet sont détaillés avec des critères d’acceptation clairs (mais pas excessifs: cinq critères maximum par story est un repère utile) et les items anciens non raffinés depuis six à huit semaines sont régulièrement questionnés et retirés si nécessaire.
Le Sprint Goal comme outil de régulation
Le Sprint Goal (objectif de sprint) est un outil de régulation souvent sous-estimé. Pour le PO fantôme, formuler un Sprint Goal oblige à s’impliquer dans la direction du sprint au-delà du simple tri de stories. Pour le PO contrôleur, le Sprint Goal définit un cadre à l’intérieur duquel l’équipe est autonome: tant que le travail contribue à l’objectif, le PO n’a pas besoin d’intervenir dans les choix d’implémentation.
Un PO qui ne parvient pas à formuler de Sprint Goal cohérent devrait se demander si le travail planifié a une cohérence stratégique ou s’il s’agit d’une collection de tâches disparates. L’absence de Sprint Goal est souvent le symptôme d’un backlog mal priorisé ou d’une vision produit insuffisamment claire.
Quel rôle pour le Scrum Master?
Le positionnement sain du PO se situe entre ces deux extrêmes: disponible sans être envahissant, décideur sans être directif, impliqué dans la stratégie sans interférer dans l’exécution technique. En pratique, cet équilibre dépend de la maturité de l’équipe (une équipe junior a besoin de plus de présence) et du stade du produit (un nouveau produit nécessite plus de guidance fonctionnelle qu’un produit mature).
Le Scrum Master joue un rôle clé dans cette régulation en observant les dynamiques d’équipe et en signalant au PO quand son positionnement dérive vers l’un ou l’autre extrême. La rétrospective reste le meilleur moment pour aborder ces questions, car le PO lui-même n’a pas toujours conscience de l’impact de son comportement sur le fonctionnement de l’équipe.