Méthode MoSCoW

En bref

La méthode MoSCoW est un système de priorisation utilisé pour déterminer l'importance relative des exigences ou des tâches dans un projet ou une planification personnelle.

Origine

• Développée dans le cadre des méthodologies de développement logiciel agile
• Popularisée par Dai Clegg lors de son travail sur la méthode DSDM (Dynamic Systems Development Method)
• Acronyme formé à partir des quatre catégories principales avec des "o" ajoutés pour faciliter la prononciation

Principe fondamental

Classer chaque exigence ou tâche dans l'une des quatre catégories suivantes:

• Must have (doit avoir)
• Should have (devrait avoir)
• Could have (pourrait avoir)
• Won't have / Would like (n'aura pas maintenant / aimerait avoir plus tard)

Les quatre catégories en détail

Must have

• Définition: Exigences ou tâches absolument essentielles
• Caractéristiques: Critiques pour le succès, non négociables, constituent le MVP (Produit Minimum Viable)
• Conséquence si absent: Échec du projet ou grave dysfonctionnement
• Proportion idéale: 20% à 40% des exigences totales

Should have

• Définition: Exigences importantes mais non vitales
• Caractéristiques: Éléments à forte valeur ajoutée, mais pouvant être retardés si nécessaire
• Conséquence si absent: Solutions de contournement possibles mais diminution de la satisfaction
• Proportion idéale: 30% à 40% des exigences totales

Could have

• Définition: Exigences souhaitables mais non essentielles
• Caractéristiques: Fonctionnalités "nice-to-have", premiers candidats à l'élimination en cas de contraintes
• Conséquence si absent: Peu d'impact sur les objectifs principaux
• Proportion idéale: 20% à 30% des exigences totales

Won't have (this time) / Would like

• Définition: Exigences reconnues mais explicitement exclues du périmètre actuel
• Caractéristiques: Éléments à considérer pour des versions futures
• Avantage de cette catégorie: Clarifier les limites du projet et gérer les attentes
• Gestion: Stocker dans un "parking lot" pour évaluation future

Processus d'application

1. Préparation

   • Lister toutes les exigences/tâches à prioriser
   • S'assurer que la liste est exhaustive et détaillée

2. Catégorisation

   • Assigner chaque élément à l'une des quatre catégories
   • Impliquer les parties prenantes dans cette décision si nécessaire

3. Équilibrage

   • Vérifier la distribution des éléments entre les catégories
   • Ajuster si une catégorie est disproportionnée (surtout "Must have")

4. Planification

   • Commencer par les "Must have"
   • Intégrer les "Should have" si les ressources le permettent
   • Considérer les "Could have" uniquement après avoir assuré les deux premières catégories

Avantages

• Facilite la communication des priorités entre les parties prenantes
• Permet de gérer efficacement les contraintes de ressources
• Aide à maintenir l'accent sur l'essentiel
• Réduit les risques de dérive du périmètre

Limites

• Peut être subjectif sans critères clairs pour la catégorisation
• Risque de voir trop d'éléments classés comme "Must have"
• Ne tient pas compte des dépendances entre les exigences
• Nécessite des révisions régulières à mesure que le contexte évolue

Applications pratiques

• Gestion de projets: Établir les priorités lors de la planification
• Développement personnel: Prioriser les objectifs et les tâches quotidiennes
• Organisation d'événements: Trier les fonctionnalités et activités à intégrer
• Gestion du temps: Clarifier ce qui doit être fait et ce qui peut attendre

Extensions et variantes

• Échelles temporelles ajoutées (Must have now, Should have this quarter...)
• Intégration avec d'autres méthodes comme Kanban ou Scrum
• MoSCoW avec scoring numérique pour affiner les priorités

Sources et références

• DSDM: Business Focused Development, Jennifer Stapleton
• Agile Project Management, DSDM Consortium
• Software Requirements, Karl Wiegers et Joy Beatty
• Date de synthèse: 9 juin 2025