Perestroïka
Il est souvent compliqué pour les parties prenantes et PO de prioriser les items du product backlog (j’évite volontairement les gommettes).
J’aime bien passer par ce petit système que j’ai créé en agrégeant pas mal de petit atelier. J’aime le principe d’entonnoir de celui-ci. Je l’ai baptisé « Perestroïka ».
On abordera deux ateliers :
- MoSCoW
- ROI priority
Atelier « MoSCoW »
L’atelier MoSCoW est simple à mettre en place. On trace 4 colonnes horizontales contenant les lettres M, S, C et W .
La première colonne contenant le M, signifiant MUST, accueillera les items/US du product backlog qu’on doit faire pour le prochain sprint.
La deuxième colonne contenant le S, signifiant SOULD, accueillera les items/US du product backlog qu’on devrait faire dans la mesure du possible pour le prochain sprint.
La troisième colonne contenant le C, signifiant COULD, accueillera les items/US du product backlog qu’on POURRAIT faire dans la mesure où cela n’a pas d’impact sur les autres items du prochain sprint.
La quatrième colonne contenant le W, signifiant WONT have now but WOULD have later, accueillera les items/US du product backlog qu’on ne peut pas faire maintenant mais qu’on pourra faire plus tard.
Le product owner et ses parties prenantes ont déjà réalisé une première priorisation macro, c’est déjà pas mal.
En tant que facilitateur, évitez tout de même que tout soit dans la colonne M 😉
Atelier « ROI priority »
Prenez ensuite la première colonne, Must, pour l’atelier ROI priority.
Faites estimer le PO et ses Parties prenantes avec les cartes de poker planning sur la valeur métier. Suivez les mêmes règles que le poker planning (https://www.youtube.com/watch?v=1jFyWvqD8q4). Réaliser la même action pour l’équipe technique, mais sur l’effort/complexité des items/US du product backlog.
ROI = « Valeur métier » x « Effort ».
Classez vos US du ROI le plus grand au plus petit, vous avez maintenant une deuxième priorisation plus juste.
À quoi bon réitérer cette action sur la colonne S? L’adaptation au changement, plus que le suivi d’un plan, quatrième valeur du manifeste agile. Concentrons nous déjà sur ce premier niveau, le Must.
Conclusion
Vous venez de fournir un outil à vos Parties prenantes et Product owner pour qu’ils puissent prioriser simplement vos items de product backlog, en amenant du débat au poker planning.
Les plus :
+ Priorisation quali
+ Pas compliqué à mettre en place.
Les moins :
– Nécessite d’avoir tous les acteurs Scrum autour de la table.
– Peut prendre plus ou moins de temps en fonction des débats lors du poker planning.
Si vous tentez, j’attends vos feedbacks 😉
