La méthode MoSCoW est une technique de priorisation qui permettra de prioriser les besoins et les exigences d’un projet souvent informatique. En Scrum, le Product Owner et les clients (métiers) la met souvent en place.
Nous avions déjà vu d’autres principes de priorisation autres que la méthode MoSCoW que vous pouvez également utiliser comme :
- le MVP (article : Qu’est-ce le MVP (Minimum Viable Product) ?)
- le modèle de Kano (article : Qu’est-ce que le modèle de Kano ?)
- le principe des quick-wins (article : Les quick wins dans le monde Agile)
- les Business Value (article : Prioriser avec les Business Value)
Certaines méthodes de priorisation peuvent se coupler pour affiner au mieux les priorisations ; vous pourrez aussi les coupler avec la méthode MoSCoW.
Le but de vous présenter toutes ces méthodes de priorisation est de vous donner la possibilité d’utiliser la (ou les) méthodes qui s’adaptent le plus au contexte dans lequel vous êtes.
Qu’est-ce que la méthode MoSCoW ?
Ce mot qui fait référence à la très belle capitale russe est un acronyme des mots suivants :
- M pour must have if ; ce qui doit être fait
- S pour should have this if at all possible ; ce qui serait bien d’être fait si c’est possible
- C pour could have this if it does not affect anything else ; ce qu’il faudrait faire si il n’y a pas d’impact avec d’autres demandes
- W pour won’t have this time but would like in the future ; à faire si nous avons le temps un jour
Vous comprendrez que les « o » avaient été rajouté à l’acronyme pour rendre l’acronyme prononçable. Il serait sinon compliqué de prononcer méthode « MSCW » au lieu de méthode MoSCoW.
Appliquer la méthode MoSCoW au monde Agile
Dans certains contextes, la méthode MoSCoW peut vraiment apporter beaucoup à la priorisation.
Le nombre de demandes dans les entreprises est souvent totalement disproportionné à la capacité de faire des équipes techniques. Et cela a des impacts quand nous ne maîtrisons pas les urgences business.
Le Product Owner (en Scrum) ou le chef de projet/AMOA va rassembler les clients des équipes techniques (les métiers) pour leur demander de définir un statut à chaque demande fonctionnelle.
Il est souvent sympa d’utiliser des petits ronds de couleurs autocollants à coller sur les post’it correspondants aux demandes fonctionnelles pour que le statut soit bien visible par tous à la suite de la réunion :
- M représenté par un rond rouge
- S représenté par un rond jaune
- C représenté par un rond orange
- W représenté par un rond vert
En Scrum, le Product Owner fait cet exercice si il en a besoin pendant la réunion de priorisation.
Dans un ou plusieurs projets complets, il est impossible de tout avoir en « must have if » et il serait même inquiétant de ne pas avoir de demandes dans les deux dernières catégories. L’animateur de la réunion aura la tâche difficile de faire comprendre aux clients qu’il y a forcément une répartition à faire sur le statut de l’ensemble des demandes. En général, le fait de faire cette priorisation tous ensemble est souvent très bénéfique et ouvre à des discussions constructives.
En cas de conflits entre différents métiers sur une demande, l’animateur invitera ceux-ci à en parler après et à laisser la priorisation de la demande en attente afin de ne pas perturber le bon déroulement de la réunion.
Conclusion
Si la méthode MoSCoW est relativement simple à mettre en pratique, elle peut s’avérer très utile quand le nombre de demande est gigantesque et qu’il devient difficile de prioriser l’ensemble.
Pourquoi ne pas utiliser cette méthode MoSCoW ? Avez-vous des expériences à nous partager avec l’utilisation de cette méthode MoSCoW ?
Lien utile : MoSCoW method (en)
Bonjour,
Nous sommes en train d’appliquer cette méthode pour nos projets et pour le moment deux questions me viennent à l’esprit :
1. Dans le cadre ou une équipe travaille sur plusieurs projets d’un groupe, devons nous prioriser les issues dans son ensemble ou par projet ? Si cela dépends, auriez-vous quelques exemples ?
2. Sur un projet interne en continuel developpement, si nous appliquons à la lettre la règle du MUST, c’est à dire une fonctionnalité vitale pour le bon fonctionnement du projet, à part pour certains bugs, nous devrions donc ne plus avoir de MUST. Suis-je dans le vrai ?
Note: Nous ne sommes pas une boite de dev, 100% de nos projets sont internes à notre groupe, avec parfois un peu d’open-source.
Merci ! 🙂
Hello,
1. Au delà que je ne recommande pas qu’une équipe travaille sur plusieurs projets en même temps, la priorisation dans ce cadre doit se faire sur l’ensemble afin de délivrer un maximum de valeur possible (en prenant en compte le ROI et les « must have »).
2. Le produit ne peut sortir sans les « MUST ». Donc il faut faire en sorte qu’à la date T de la release, tous les MUST devront avoir été fait.
Pas de soucis, le contexte ne change pas mes réponses 🙂