Qu’est-ce que la méthode MoSCoW ?
Imaginée par Dai Clegg, consultant chez Oracle, en 1994, la Méthode MoSCoW est un outil de Product Management qui vise à aider les équipes de développement à prioriser leur backlog produit. Au même titre que le User Story Mapping, cet exercice offre un cadre de réflexion pour déterminer les différentes versions cible d’un même produit en fonction de l'importance des besoins utilisateurs visés et des contraintes techniques endogènes (sécurité, fiabilité, etc.) ou exogènes (réglementation, dépendances avec le reste de l’organisation, etc.) de l’équipe.
Simple à mettre en place et particulièrement utile pour piloter un projet limité par le temps et/ou les ressources, la Méthode MoSCoW invite les équipes de développement à classer le champ des fonctionnalités possibles par ordre d’importance, selon 4 degrés de priorité :
- M pour Must have this : Les fonctionnalités fondamentales nécessaires à la satisfaction des attentes des utilisateurs et/ou des contraintes indépassables en matière de sécurité ou de fiabilité produit.
- S pour Should have this if at all possible : Les fonctionnalités nécessaires à la différenciation du produit par rapport aux concurrents. Elles apportent une valeur certaine aux utilisateurs mais sont cependant moins essentielles que les fonctionnalités précédentes et, par conséquent, moins urgentes à implémenter.
- C pour Could have this if it does not affect anything else : Le développement de ces fonctionnalités peut représenter un vrai plus dans le succès commercial du produit. Si l’équipe a le temps de les implémenter sans que cela n’affecte la réalisation des fonctionnalités plus essentielles, elles sont à faire. En revanche, si le projet accuse déjà un certain retard, ce sont des fonctionnalités qui peuvent être sacrifiées pour assurer une livraison en temps et en heure d’une version produit moins étoffée.
- W pour Would like but won’t get this time : Ce sont des fonctionnalités qui n’ont que très peu de chances d’être réalisées à moyen terme. Elles sont les dernières par ordre d’importance et mises de côté pour le moment. Si la situation évolue, ces fonctionnalités pourront éventuellement remonter dans l’ordre des priorités.
Comment utiliser la Méthode MoSCoW en atelier ?
Afin d’assurer le respect du processus classique de divergence et de convergence d’une session de réflexion collective, l’atelier de la méthode MoSCoW se déroule en trois étapes:
- Listez les tâches à effectuer : L’équipe se réunit et brainstorme collectivement pour lister toutes les tâches relatives à l’exécution du projet, sans souci de les classer dans ce premier temps. Elles sont rassemblées et soumises à réflexion : certaines fonctionnalités peuvent-elles être divisées en plusieurs fonctionnalités plus petites ? Faut-il, au contraire, regrouper des fonctionnalités qui ne peuvent pas être développées de façon autonome ? Quelles sont les éventuelles dépendances internes ou externes ?
- Priorisez les actions : Il s’agit de classer les fonctionnalités selon les 4 degrés de priorité précédemment cités : Quelles fonctionnalités sont absolument fondamentales pour proposer un produit fonctionnel et attractif ? Lesquelles sont également essentielles mais moins urgentes ? Quelles fonctionnalités peuvent être développées si le temps le permet ? Et enfin, quelles fonctionnalités sont retirées du projet pour le moment ? En répondant à ces questions, l’équipe priorise les actions en faisant des arbitrages. Certains intérêts risquent de diverger : vous pouvez alors parvenir à un consensus et objectiver le processus de prise de décision en vous appuyant sur un vote ou un référentiel de priorisation de type Valeur Business-Complexité.
- Validez la classification : L’enjeu principal de cette ultime étape est de s’assurer que la liste des Must est aussi succincte que possible. La classification doit être validée et acceptée par tous les participants : l’alignement de l’équipe sur les décisions prises est essentiel pour son bon fonctionnement par la suite. Pour valider l’orientation stratégique et lever les éventuels freins ou dépendances organisationnels, il peut être opportun de faire valider le fruit de l’atelier par les décideurs du projet.