Priorisation du Backlog avec MoSCoW

Bonjour !

Dans la leçon précédente, nous avons appris à estimer la charge de travail des user stories avec les story points. Nous avons maintenant une idée de la "taille" de chaque fonctionnalité. Cependant, un backlog de produit peut contenir des dizaines, voire des centaines de stories. La question fondamentale est donc : par où commencer ?

L'objectif de cette leçon est de répondre à cette question en apprenant à prioriser un backlog de produit avec la méthode MoSCoW. C'est une compétence essentielle pour s'assurer que l'équipe de développement concentre ses efforts sur ce qui apporte le plus de valeur au client et à l'entreprise, tout en gérant les attentes de manière transparente.

1. Qu'est-ce que la méthode MoSCoW ?

Lorsque vous discutez avec un client, il est fréquent d'entendre que "tout est prioritaire". La méthode MoSCoW est un cadre de négociation et de clarification puissant qui aide toutes les parties prenantes (client, Product Owner, équipe) à se mettre d'accord sur le degré de nécessité de chaque exigence.

Son nom est un acronyme (les "o" ont été ajoutés pour le rendre prononçable) qui classe les fonctionnalités en quatre catégories distinctes.

Pour bien comprendre ces catégories, je vous propose de lire l'extrait suivant d'un article qui les définit clairement.

Comprendre la méthode MoSCoW pour prioriser les exigences projet

Cet article de la Wild Code School offre une excellente introduction à la méthode MoSCoW en français. Il vous permettra de vous familiariser rapidement avec le concept et la définition de chaque catégorie.

Lisez les sections suivantes : 'Qu’est-ce que la méthode MoSCoW ?' et 'Les 4 catégories en détail'. Concentrez-vous sur la signification précise de chaque terme : Must, Should, Could, et Won't.

Pour résumer et approfondir, voici ce que chaque catégorie implique :

M - Must have (Doit avoir)
- Définition : Non négociable. La fonctionnalité est fondamentale pour que le produit soit viable. Sans elle, le lancement n'a pas de sens ou le produit est illégal/inutilisable.
- Question clé : "Que se passe-t-il si nous livrons le produit sans cette fonctionnalité ?" Si la réponse est "le produit ne fonctionnera pas" ou "nous ne pourrons pas l'utiliser", alors c'est un Must have.
S - Should have (Devrait avoir)
- Définition : Important, mais pas vital. Son absence sera douloureuse ou inefficace pour l'utilisateur, mais il existe des solutions de contournement (même si elles sont peu pratiques).
- Question clé : "Le produit peut-il fonctionner sans ça ?" Si la réponse est "oui, mais...", c'est probablement un Should have.
C - Could have (Pourrait avoir)
- Définition : Souhaitable, mais pas nécessaire. C'est ce qu'on appelle souvent le "nice-to-have". Ces fonctionnalités ont un impact limité si elles sont laissées de côté et sont les premières à être abandonnées si le temps manque.
- Question clé : "Quel est l'impact si nous n'incluons pas cette fonctionnalité ?" Si la réponse est "un faible impact", c'est un Could have.
W - Won't have (N'aura pas... pour l'instant)
- Définition : Explicitement hors du périmètre pour la période de temps considérée (sprint, release, etc.). C'est une catégorie cruciale pour gérer les attentes. Cela ne veut pas dire "jamais", mais "pas maintenant". Cela permet de garder le backlog futur organisé sans polluer la priorisation actuelle.

2. MoSCoW en action : Un processus collaboratif

La priorisation MoSCoW n'est pas un exercice solitaire. Sa valeur réside dans la discussion et l'alignement qu'elle crée au sein de l'équipe et avec les parties prenantes.

La vidéo suivante, bien qu'en anglais, simule très bien une session de priorisation en équipe et montre la dynamique de collaboration.

Agile in Practice: Prioritisation using MoSCoW

Regardons comment une équipe agile utilise MoSCoW en pratique. Cette simulation met en évidence le rôle du Product Owner et l'importance du dialogue pour arriver à une compréhension partagée de la valeur métier.

Regardez les passages suivants : De 0:56 à 1:45 : L'explication des quatre catégories dans un contexte d'équipe. De 1:45 à 3:02 : La discussion pour classer deux user stories. Remarquez comment le Product Owner justifie ses choix et comment l'équipe parvient à un consensus. C'est le cœur du processus.

Ce que cette vidéo illustre parfaitement, c'est que :

Le Product Owner a le dernier mot sur la priorisation, car il est responsable de la valeur du produit.
L'équipe entière participe pour poser des questions, challenger les hypothèses et s'assurer que tout le monde comprend pourquoi une fonctionnalité est un Must have et une autre un Could have.
À la fin, l'équipe effectue un "sanity check" : si l'on ne livrait que les Must haves, aurions-nous un produit cohérent et utilisable ? Si la réponse est non, la priorisation doit être revue.

3. Mise en pratique : Priorisons le backlog de "Chez Antoine"

Appliquons maintenant cette méthode à notre projet de site de commande en ligne pour le restaurant "Chez Antoine". Imaginez que vous êtes en réunion avec le client (Antoine) et l'équipe. L'objectif est de définir le périmètre du Minimum Viable Product (MVP), c'est-à-dire la toute première version à mettre en ligne.

Voici le backlog de user stories que nous avons identifiées :

US1 : En tant que client, je veux consulter la carte du restaurant pour voir les plats disponibles.
US2 : En tant que client, je veux ajouter un plat à mon panier pour le commander.
US3 : En tant que client, je veux valider mon panier et payer ma commande en ligne.
US4 : En tant que client, je veux créer un compte pour sauvegarder mes informations et voir mon historique de commandes.
US5 : En tant que client, je veux laisser un avis sur un plat que j'ai commandé.
US6 : En tant qu'utilisateur, je veux pouvoir changer le thème du site (mode clair/sombre) pour mon confort visuel.

Votre exercice (10 minutes) :
Prenez quelques minutes pour classer ces 6 user stories dans les catégories MoSCoW, en gardant à l'esprit l'objectif du MVP : permettre aux clients de commander en ligne le plus vite possible.

Ma proposition de priorisation pour le MVP

Voici comment je classerais ces fonctionnalités, avec les justifications correspondantes :

User Story	Priorité	Justification
US1 : Consulter la carte	Must	Sans cela, un client ne peut même pas savoir ce qu'il peut commander. C'est le point de départ absolu.
US2 : Ajouter au panier	Must	C'est le mécanisme de base de la commande. Impossible de commander sans pouvoir sélectionner des plats.
US3 : Valider et payer	Must	C'est l'étape qui finalise la commande et génère du chiffre d'affaires. Sans paiement, le système est inutile pour le restaurant.
US4 : Créer un compte	Should	C'est très important pour la fidélisation, mais pour un MVP, on pourrait imaginer un mode "invité" pour ne pas freiner la première commande. Le produit reste fonctionnel sans compte obligatoire.
US5 : Laisser un avis	Could	C'est une fonctionnalité intéressante pour l'engagement et la preuve sociale, mais elle n'est pas du tout nécessaire pour passer une commande. Elle peut être ajoutée dans une version ultérieure.
US6 : Thème clair/sombre	Won't	C'est une amélioration de confort qui n'apporte aucune valeur métier directe pour le MVP. On décide explicitement de ne pas le faire maintenant pour se concentrer sur le cœur du métier.

Voici à quoi peut ressembler un tableau de bord de priorisation MoSCoW une fois finalisé pour un projet plus conséquent.

MoSCoW Method Application Example — Cet exemple illustre comment les fonctionnalités d'une application de gestion de projet sont réparties dans les quatre catégories MoSCoW, offrant une vue d'ensemble claire des priorités de développement.

4. Pièges et bonnes pratiques

Pour utiliser MoSCoW efficacement, gardez ces points en tête :

Le piège du "tout est Must have" : C'est un problème courant. Pour le contrer, une bonne pratique consiste à limiter les Must haves à environ 60% de l'effort total d'un cycle de développement (release ou sprint). Les 40% restants (composés de Should et Could) agissent comme une zone tampon. Si des imprévus surviennent, on peut abandonner des Could ou des Should sans compromettre la livraison du cœur de produit (les Musts).
Différencier priorité et effort : MoSCoW définit la priorité (la valeur métier), tandis que les story points définissent l'effort. Une fonctionnalité peut être un Must have mais ne coûter qu'un seul point, alors qu'un Could have pourrait en coûter 13. La combinaison des deux est essentielle pour la planification.
La subjectivité : La priorisation peut être subjective. C'est pourquoi le rôle du Product Owner est crucial. C'est lui qui tranche en se basant sur la vision du produit et les objectifs business, après avoir écouté toutes les parties prenantes.

Conclusion

Félicitations ! Vous maîtrisez maintenant une technique de priorisation agile simple et redoutablement efficace. En distinguant clairement ce qui est indispensable de ce qui est souhaitable, la méthode MoSCoW vous permet de focaliser les ressources là où elles comptent le plus.

Points clés à retenir :

MoSCoW classe les exigences par niveau de nécessité : Must, Should, Could, Won't.
C'est un outil de communication et de négociation pour aligner l'équipe et les parties prenantes.
La catégorie Won't have est essentielle pour gérer les attentes et définir un périmètre clair.
Prioriser avec MoSCoW (valeur) et estimer avec les story points (effort) sont deux activités complémentaires qui forment la base d'une planification agile saine.

Maintenant que nous avons un backlog de produit à la fois estimé en complexité et priorisé en valeur, nous sommes prêts pour l'étape suivante. Dans la prochaine leçon, nous allons apprendre à planifier un sprint, en sélectionnant les tâches les plus prioritaires qui peuvent être réalisées dans une période de temps donnée, en fonction de la capacité de l'équipe.