Comprendre les quatre niveaux de priorité
MoSCoW classe les besoins selon leur importance réelle pour la réussite du projet. La méthode est utile pour des fonctionnalités, des exigences, des livrables ou même des lots de travail.
Le classement doit refléter les conséquences d’une absence, pas la préférence personnelle de celui qui formule la demande.
Must, Should, Could, Won’t
Chaque niveau répond à une question différente.
- Must have : sans cet élément, le projet ou la livraison n’est pas acceptable.
- Should have : très important, mais une solution temporaire ou un report reste possible.
- Could have : apporte de la valeur si la capacité le permet.
- Won’t have for now : volontairement exclu de la version ou période actuelle.
Définir des critères avant de classer
Pour éviter que toutes les demandes deviennent des Must, définissez des critères : obligation réglementaire, dépendance critique, sécurité, valeur utilisateur, impact métier, engagement contractuel ou risque opérationnel.
Demandez systématiquement : que se passe-t-il si cet élément n’est pas livré maintenant ? Si la réponse est “ce serait moins confortable”, il s’agit probablement d’un Should ou Could.
Limiter les Must
Une liste composée majoritairement de Must indique souvent que la priorisation n’a pas réellement été faite. Gardez de la capacité pour absorber les imprévus et permettre des arbitrages.
Prioriser collectivement avec les bonnes parties prenantes
La priorisation ne doit pas être décidée uniquement par l’équipe de réalisation. Le métier, les utilisateurs, le sponsor et les fonctions contraintes doivent contribuer lorsque leurs enjeux sont concernés.
Organisez une session courte avec la liste des besoins, les critères d’arbitrage et la capacité disponible. Les désaccords deviennent alors visibles et peuvent être tranchés explicitement.
Documenter la raison du classement
Une courte justification évite de recommencer le débat à chaque réunion. Notez la raison, le décideur et éventuellement la date de révision.
Relier MoSCoW au planning et au périmètre
La priorité doit avoir une conséquence concrète. Les Must sont planifiés en premier et sécurisés. Les Should sont intégrés tant que la trajectoire reste soutenable. Les Could constituent la première zone d’ajustement en cas de dérive.
Les Won’t ne sont pas supprimés définitivement : ils sont assumés comme hors périmètre de la période actuelle et peuvent alimenter un backlog futur.
Exemple de projet web
Pour un formulaire de contact : consentement, validation et réception du message peuvent être Must ; accusé de réception personnalisé Should ; animation de succès Could ; espace client Won’t pour cette version.
Revoir les priorités lorsque le contexte change
Une priorité n’est pas immuable. Une nouvelle contrainte réglementaire, un risque, un retour utilisateur ou une dépendance peut modifier l’ordre.
Réévaluez MoSCoW aux principaux jalons et avant tout arbitrage important de périmètre. La méthode reste efficace si elle reflète la situation actuelle.
Éviter le piège du “tout urgent”
Séparez urgence et importance. Une demande urgente peut être peu importante pour l’objectif du projet, tandis qu’un Must peut nécessiter une préparation longue mais non urgente aujourd’hui.
Checklist de mise en pratique
Avant de considérer le sujet comme maîtrisé, vérifiez ces points dans votre projet.
- Critères définis.
- Must limités.
- Arbitrage partagé.
- Raisons tracées.
- Priorités reliées au planning.
Continuer avec les conseils liés
Conclusion
Cette méthode devient réellement utile lorsqu’elle est appliquée avec régularité et adaptée au contexte du projet. L’objectif n’est pas de produire davantage de documentation, mais de rendre les décisions, responsabilités et arbitrages plus explicites.