Au sein d’une équipe Scrum, le Product Owner est une figure centrale. Il définit la vision produit, gère le backlog produit et s’assure que les priorités sont bien établies et comprises à travers la manipulation d’items appelés “User Story”. Une user story est une succession de phrases qui décrivent le comportement final du point de vue de l’utilisateur. Prioriser les User Stories fait partie intégrante de ce que le Product Owner doit nécessairement entreprendre, impliquant, comme cela se doit, non seulement une compréhension approfondie des besoins des utilisateurs mais aussi des objectifs commerciaux et de la capacité de l'équipe de développement. Cela signifiera adopter une approche d’accompagnement agile pour améliorer la manière dont les équipes perçoivent et travaillent avec les priorités afin de garantir une livraison de valeur produit plus efficace et reflétant ainsi les attentes des parties prenantes.
Cet article introduira, via des exemples amusants, des stratégies pour optimiser la priorisation des user stories.
Être un Product Owner Scrum signifie non seulement prioriser les user stories par rapport à ce qui doit être fait en premier, mais cela signifie également comprendre le pourquoi derrière chaque fonctionnalité, comment cela va affecter l'utilisateur final et comment cela s'alignera finalement avec les objectifs à long terme du produit. Avec l'approche de coaching agile, on mène l'équipe dans le processus réflexif de discussions ouvertes sur la valeur de chaque histoire et à quel point elle s'aligne sur la vision du produit.
Certaines des stratégies de priorisation incluent :
1. La matrice de priorité
Imaginez un jeu de société où chaque case représente une user story avec différents niveaux de valeur et d'urgence. La Matrice de Priorité est construite sur la même inspiration que la Matrice d'Eisenhower et divise les histoires en :
- Pas Important mais Urgent
- Pas Important et pas Urgent
- Important et Urgent
- Important mais Pas Urgent
Cela rendra les choses beaucoup plus faciles pour l'équipe car ils pourront visualiser ce qui doit être fait en premier, en considérant ce dont ils ont besoin maintenant et en faisant des investissements (techniques ou non) à long terme.
2. Le planning poker
Une sorte de jeu de cartes où chaque membre de l'équipe possède un certain nombre de points à attribuer aux user stories, en concordance avec sa perception de la priorité de l'histoire. Cette manière démocratique de recueillir les opinions et de mettre en évidence les histoires qui apportent le plus de valeur selon l'équipe. C'est un autre jeu engageant que l’on peut utiliser. Il est pratique pour garantir que tous les points de vue sont pris en considération.
3. Le jeu : Buy a feature
Dans ce jeu, chaque participant reçoit une quantité fictive d'argent avec laquelle il peut "acheter" les fonctionnalités qui, selon lui, sont les plus importantes. Cela amène stratégiquement les membres de l'équipe à bien gérer leurs porte monnaie afin de réfléchir à la valeur qu'ils veulent attribuer à chaque fonctionnalité et encourage une discussion sur ce qui est essentiel pour le produit. C'est une manière ludique et puissante de créer l'adhésion de l'équipe aux priorités.
4. Le Story Mapping
Pensez maintenant à un très grand plateau de jeu où les user stories sont ordonnées selon leur séquence dans le parcours utilisateur et leur priorité. Le story mapping est une activité très collaborative, donc le but est de comprendre en réalité comment les différentes histoires sont liées entre elles et si elles créent une expérience utilisateur cohérente. Cela aura pour but de démontrer à quel point les fonctionnalités sont critiques, étant donné leur impact sur le parcours utilisateur, et aidera l'équipe à rester concentrée sur la manière dont elles apportent de la valeur à chaque décision qu'elles prennent.
5. La méthode MoSCoW
Vous êtes à présent un groupe qui a pour objectif de construire le parc d'attractions idéal. Pour ce faire, il faut planifier et prioriser les services et les activités proposées. Nous allons utiliser la méthode MoSCow. Chaque participant va classer ses idées d’activités/services en quatre catégories :
- Must Have : Tout ce qui est vital au projet et à sa réalisation/réussite.
- Should Have : Non essentiel au projet mais apporte une réelle valeur ajoutée.
- Could Have : Activités de confort, leur réalisation n’a pas d’incidence sur le projet.
- Won’t Have : Activités abandonnées pour le moment ou non réalisables.
Chaque membre présente sa version du parc d’attractions idéal avec ses activités et services en expliquant la raison pour laquelle ils ont placé chaque activité/service dans une des catégories du MoSCoW. Ce qui va permettre d’ouvrir le débat sur l’importance de chaque activité et encourager les compromis.
Cet atelier vise à montrer de manière concrète et amusante comment la méthode MoSCoW peut être utilisée pour prioriser efficacement dans un projet, en distinguant ce qui est essentiel de ce qui est simplement souhaitable ou superflu.
Voici à présent quelques exemples d’ateliers de priorisation qu’un PO peut faire avec les métiers pour prioriser les fonctionnalités de son produit tout en incluant un peu de fun sont ci-dessous :
Exemple #1 : Restaurant Agile
Imaginez gérer un restaurant virtuel où chaque fonctionnalité représente un plat à ajouter au menu. Si un certain plat qu'un client a demandé à introduire au menu est listé comme très populaire (donc important à inclure au menu) et peut être facilement développé, alors la matrice de priorisation peut aider à prendre la décision de ce choix (on peut supposer du ratio importance/urgence de ce plat). Cela peut être un scénario léger, pour une introduction de la manière dont les décisions de priorisation affecteront toute l'expérience client.
Exemple #2 : La Course aux Trésors
Pensez à chaque fonctionnalité comme un trésor caché dans un jeu de chasse au trésor. Les participants doivent décider du chemin à prendre pour collecter les trésors les plus précieux (histoires ayant une grande valeur) tout en traversant des obstacles (contraintes de métiers ou de développement). En fin de compte, c'est un bon exemple qui fait réfléchir les participants stratégiquement car différentes priorités porteront sur la manière dont le voyage vers la fin est bien réalisé tout en ayant une approche pour délivrer un produit à haute valeur métier.
Conclusion
Définir les User Stories dans le Product Backlog en Scrum pour un Product Owner à l'esprit Agile est un art exigeant de l'empathie, de la stratégie et de la communication. À travers des manières ludiques et interactives qui rendent le processus engageant et impliquant, le processus est converti en une expérience éducative pour toute l'équipe. Cela optimise non seulement en termes de livraison de valeur, mais renforce également la cohésion de l'équipe et l'alignement dans sa vision du produit.
