MoSCoW
Classez vos exigences en Must, Should, Could et Won't. La méthode MoSCoW de Dai Clegg pour protéger l'essentiel quand le temps presse.
Description
La méthode MoSCoW est une technique de priorisation créée par Dai Clegg (Oracle UK, 1994) qui classe les exigences d'un projet en quatre catégories (Must have, Should have, Could have, Won't have this time) pour concentrer les efforts sur les fonctionnalités à plus forte valeur dans un cadre temporel fixe. Publiée dans CASE Method Fast-Track: A RAD Approach (Addison-Wesley, 1994, co-écrit avec Richard Barker), elle a ensuite été standardisée par le consortium DSDM (devenu Agile Business Consortium) à partir de 2002. Votre sprint démarre lundi, votre backlog contient 40 items et votre équipe en livre 15 par sprint. Qui décide lesquels passent ? Sans cadre partagé, la priorisation MoSCoW répond à cette question avec une logique que tout le monde comprend en cinq minutes. Un Must have, c'est ce sans quoi le produit ne fonctionne pas : si vous construisez un site e-commerce, le panier d'achat est un Must have. Un Should have apporte une valeur significative mais n'empêche pas la livraison : les filtres de recherche avancés. Un Could have serait agréable si le temps le permet : les recommandations personnalisées. Un Won't have this time est explicitement reporté, pas oublié. La priorisation MoSCoW fonctionne comme le tri d'un chirurgien de campagne : vous sauvez d'abord les cas critiques, puis vous traitez les cas importants, puis les cas secondaires si les ressources le permettent. Le DSDM recommande une règle précise : les Must have ne doivent pas dépasser 60% de l'effort total estimé, laissant 40% de tampon réparti entre Should et Could. Ce tampon protège vos Must have en cas de dépassement. Contrairement aux frameworks de scoring comme RICE ou ICE qui produisent un classement numérique continu, la méthode MoSCoW force une décision catégorielle binaire : c'est essentiel ou ça ne l'est pas. Cette simplicité est sa force dans les contextes où la vitesse de décision prime sur la granularité analytique.
Objectifs
- Prioriser les fonctionnalités
- Prioriser le travail
- Améliorer la collaboration d'équipe
Utilisé par
- -Oracle UK (entreprise d'origine où Dai Clegg a créé la méthode MoSCoW en 1994)
- -BBC (utilise la méthode MoSCoW dans ses projets digitaux pour prioriser les exigences sous contrainte de temps)
- -Spotify (applique MoSCoW en complément de ses processus agiles pour les décisions de scope au niveau squad)
Avantages
- Décision en 5 minutes par item. La catégorisation binaire (essentiel ou pas) élimine les débats de scoring interminables.
- Protection du périmètre critique. La règle des 60% garantit que vos Must have seront livrés même si les estimations sont optimistes.
- Langage universel. "C'est un Must ou un Should ?" est compréhensible par tout le monde, du développeur au CEO.
- Idéal pour le timeboxing agile. La méthode MoSCoW est conçue pour les deadlines fixes où le scope doit s'adapter au temps, pas l'inverse.
Limites
- Pas de granularité dans le classement. Deux Must have ont le même statut même si l'un est 10x plus critique que l'autre. Pour un classement fin, utilisez RICE ou ICE en complément.
- Subjectivité de la catégorisation. Ce qui est Must pour le PM peut être Should pour le Tech Lead. L'atelier collectif atténue ce biais, mais ne l'élimine pas.
- Ne capture pas l'effort. La méthode MoSCoW dit quoi faire, pas combien ça coûte. Combinez avec des estimations d'effort pour éviter un sprint avec 15 Must have impossibles à livrer.
- Risque de "tout est Must have". Si les stakeholders classent 80% des items en Must, la méthode perd son utilité. Appliquez la règle des 60% sans exception.
Comment appliquer MoSCoW
- 1
Lister toutes les exigences du périmètre
Videz votre backlog, vos demandes clients, vos contraintes techniques et vos idées d'équipe dans une liste unique. Chaque item doit être formulé comme un besoin concret, pas comme une solution technique. Visez 15-40 items. Au-delà, segmentez par thème ou par release. Output : une liste exhaustive visible par toutes les parties prenantes.
- 2
Définir la contrainte de temps (timebox)
La méthode MoSCoW fonctionne dans un cadre temporel fixe : sprint, release, trimestre. La date est immuable, le périmètre s'ajuste. Sans cette contrainte, la distinction entre Must et Should perd son sens. Fixez la date de livraison et la capacité disponible de l'équipe. Output : une timebox claire avec capacité estimée en jours/points.
- 3
Catégoriser chaque exigence en atelier collectif
Réunissez PM, Tech Lead, Designer et 1-2 stakeholders métier. Pour chaque item, posez la question : "Si nous ne livrons pas ceci dans cette timebox, que se passe-t-il ?" Si la réponse est "le produit ne fonctionne pas" ou "nous perdons des clients", c'est un Must have. Si c'est "c'est dommage mais on survit", c'est un Should ou Could. Si c'est "pas maintenant", c'est un Won't. Débattez 2 minutes par item, pas plus. Output : chaque item classé dans une des 4 catégories.
- 4
Vérifier la règle des 60%
Calculez l'effort total des Must have. S'il dépasse 60% de votre capacité, vous avez trop de Must have. Rétrogradez les items les moins critiques en Should have. Ce tampon de 40% n'est pas du gaspillage, c'est votre assurance qualité : il absorbe les imprévus, les bugs, les estimations optimistes. Output : répartition validée respectant la règle 60/20/20.
- 5
Planifier l'exécution par priorité
Démarrez par les Must have. Ils sont non négociables et doivent être terminés en premier. Passez ensuite aux Should have. S'il reste du temps, attaquez les Could have. Si un Must have prend plus de temps que prévu, sacrifiez un Could have, jamais un autre Must have. Output : plan d'exécution ordonné avec dépendances identifiées.
- 6
Documenter les Won't have avec justification
Le Won't have n'est pas une poubelle. Chaque item rejeté doit avoir une justification écrite et un horizon de reconsidération (prochain sprint, prochaine release, Q3). Partagez cette liste avec les stakeholders pour éviter les "mais je croyais qu'on avait dit oui". Output : liste Won't have documentée et partagée.
- 7
Réviser la catégorisation à chaque sprint/release
Un Should have de ce sprint peut devenir un Must have du prochain si le contexte change (feedback utilisateur, pression concurrentielle, contrainte réglementaire). Revisitez votre catégorisation au début de chaque cycle. Output : catégorisation mise à jour avec justifications des changements.