Prioriser avec la méthode MoSCoW

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, elle est souvent mise en place par le Product Owner et les clients (métiers).

Nous avions déjà vu d’autres principes de priorisation que vous pouvez également utiliser comme :

Certaines méthodes de priorisation peuvent se coupler pour affiner au mieux les priorisations.

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 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 on a le temps un jour

Vous comprendrez que les “o” avaient été rajouté à l’acronyme pour rendre l’acronyme prononçable.

Appliquer MoSCoW au monde Agile

Dans certains contextes, la méthode MoSCoW peut vraiment apporter beaucoup à la priorisation.

Il n’est pas rare dans les entreprises de voir le nombre de demandes totalement disproportionnées à la capacité de faire des équipes techniques. Et cela a des impacts quand on ne maîtrise 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 :

  1. M représenté par un rond rouge
  2. S représenté par un rond jaune
  3. C représenté par un rond orange
  4. W représenté par un rond vert
autocollant rond de couleur
autocollant rond de couleur

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.

 

One Reply to “Prioriser avec la méthode MoSCoW”

Leave a Reply

Your email address will not be published. Required fields are marked *