Méthode MoSCoW : prioriser les exigences après une réunion
Appliquez MoSCoW aux exigences issues d’une discussion : Must, Should, Could et Won’t pour la période en cours. Avec un exemple, des questions pour l’équipe et un modèle de décision.
La priorité dépend de l’objectif et de la période
En réunion, chacun a jugé sa fonctionnalité indispensable. Une telle liste ne permet pas de fixer un périmètre. Convenez d’abord du résultat attendu de la prochaine version et de ce qui la rendrait inutilisable. Les priorités peuvent être très différentes pour une autre étape.
MoSCoW comprend quatre catégories : Must Have, Should Have, Could Have et Won’t Have this time. La dernière écarte délibérément une exigence pour la période considérée. Elle ne constitue ni une promesse pour plus tard ni un abandon définitif.
Discutez des conséquences d’une exclusion
Décrivez l’objectif de la version
Précisez l’utilisateur, sa tâche et les conditions d’usage. Clarifiez les contraintes et l’horizon de planification. Si l’objectif se résume à « améliorer le produit », chacun appliquera ses propres critères et presque tout sera jugé indispensable.
Évaluez les exigences candidates à Must
Pour chacune, demandez si le résultat resterait utilisable sans elle. Étudiez les solutions de contournement acceptables et les dépendances. Une exigence indispensable doit avoir une justification précise. « La direction l’a demandé » indique l’origine, sans décrire les conséquences d’une exclusion.
Distinguez ce qui est important de ce qui est souhaitable
Une exigence Should est importante. Son absence dégrade nettement le résultat, qui reste utilisable. Une exigence Could est un complément utile, plus facile à écarter. Expliquez l’écart par le cas d’usage et le coût de l’omission, au-delà de « c’est vraiment nécessaire ».
Convenez des exclusions et des conditions de révision
Pour chaque Won’t de cette période, notez le motif et la condition qui justifierait de rouvrir la discussion. Vérifiez les dépendances et la faisabilité du périmètre. Si les exigences indispensables dépassent la capacité disponible, revoyez le périmètre ou le plan. Changer la catégorie ne résout pas un manque de ressources.
Première version d’un formulaire d’inscription à un événement
L’exemple pédagogique ci-dessous est fictif. Les noms, les conditions et les résultats servent uniquement à expliquer la méthode.
Nous devons accepter une demande et confirmer la place. Pouvoir choisir la couleur du badge serait agréable, mais l’événement peut avoir lieu sans cela. Pour l’instant, nous n’avons pas le temps de discuter d’un espace personnel.
Dans cet exemple, l’objectif est d’inscrire une personne et de lui donner une confirmation claire. Déposer une demande est un Must, car sans cela le parcours principal disparaît. Un rappel peut être un Should si l’équipe dispose d’une solution temporaire convenue.
La couleur du badge peut être un Could et l’espace personnel peut être exclu pour cette période. Ce classement vaut pour cet exemple. Les conséquences seraient différentes pour un autre événement ou un autre public.
| Exigence | Catégorie | Justification |
|---|---|---|
| Déposer une demande | Must | Sans cela, le parcours principal disparaît |
| Recevoir un rappel | Should | Important, avec un contournement temporaire |
| Choisir la couleur du badge | Could | N’empêche pas l’inscription |
| Espace personnel | Won’t pour cette fois | Hors du périmètre convenu |
Fiche de justification d’une priorité
Conservez la justification avec la catégorie. Vous pourrez ainsi revenir sur la décision si les conditions changent.
Version / période / objectif : Exigence : Parcours utilisateur : Conséquences si l’exigence est écartée : Contournement acceptable, le cas échéant : Dépendances : Catégorie MoSCoW : Justification : Personne ayant confirmé la décision : Condition de révision : Exclusions pour cette période :
Vérifiez que la liste aide à choisir
- L’objectif et la période figurent à côté des catégories.
- Les conséquences d’une exclusion sont indiquées pour chaque Must.
- Tout contournement temporaire a été évalué explicitement.
- Won’t pour cette fois est compris comme une exclusion de la période en cours.
Dans le détail
Une exigence peut-elle changer de catégorie ?
Oui, si l’objectif, la période ou une dépendance change, ou si de nouvelles informations apparaissent. Notez la raison et convenez des effets sur le périmètre avant de déplacer l’exigence.
Que faire si toutes les exigences sont classées Must ?
Demandez ce qui rend le résultat inutilisable en l’absence de chaque exigence, examinez les contournements et resserrez l’objectif. Si le périmètre indispensable reste trop vaste, revoyez le plan.