MoSCoW : cette méthode géniale vous aide à prioriser vos tâches !

Laissez tout de suite tomber votre liste des choses à faire, la méthode MoSCoW vous permet de classifier les choses à faire de manière simple et efficace. 

Commençons par le commencement, MoSCoW vient de Must, Should, Could et Won’t, en français doit, devrait, pourrait, ne sera pas. Cette méthode est largement utilisée en développement logiciel par les équipes agiles. Plus qu’un simple to-do list, la méthode MoSCoW suggère de classer les choses à faire dans les 4 catégories expliquées ci-dessous.

Classer les tâches avec MoSCoW

Must regroupe les fonctionnalités qu’il faut absolument implémenter. Sans elles, un MVP (Minimum Viable Product) est difficilement envisageable. Ce sont les fonctionnalités vitales.

La question à se poser est : est-ce que mon produit peut être appelé en tant que tel s’il n’a pas cette fonctionnalité ? Si non, alors c’est un must.

Should contient les fonctionnalités essentielles, celles qui doivent être réalisées dans la mesure du possible.

La question à se poser est : est-ce que sans cette fonctionnalité, mon produit peut quand-même rivaliser avec d’autres produits concurrents ? Si non, alors c’est un should.

Could regroupe les fonctionnalités de confort, celles qui peuvent être là pour faciliter la vie de l’utilisateur mais ne sont pas obligatoires.

La question à se poser est : est-ce qu'avec cette fonctionnalité, mon produit peut se classer parmi les bons produits concurrents ? Si oui, alors c’est un could, sinon c’est un won’t.

Won’t contient les fonctionnalités qui ne seront pas réalisées cette fois, mais une prochaine fois. Ces fonctionnalités ne sont qu’un luxe.

Dans l’ordre, on doit donc réaliser les tâches M, puis les S, puis les C. Ou vu sous un autre angle, dans le cas où l’on manque de temps, on abandonne progressivement les tâches C, puis les S. Si vous en arrivez à abandonner les M, posez-vous des questions, il y a certainement d’autres problèmes que la méthode MoSCoW ne peut pas résoudre.

Un exemple : le blog

Pour l’exemple, voici une liste des tâches qui pourraient appartenir à un projet de réalisation d’un blog.

• Consultation des articles
  • Must : c’est LA fonctionnalité d’un blog, le produit n’est pas fonctionnel si elle n’est pas implémentée.
• IA pour recommander les articles aux lecteurs
  • Won’t : c’est un luxe, ce n’est absolument pas essentiel et ça peut être fait la prochaine fois. Je peux réaliser un bon blog même sans cette fonctionnalité.
• Comptes utilisateur
  • Should : ce n’est pas vital comme la consultation des articles, un blog peut fonctionner sans, mais c’est plus qu’un simple confort, ça donne l'accès à beaucoup de fonctionnalités sous-jacentes.
• Commentaires
  • Should : il s’agit d’une fonctionnalité importante d’un blog, même si ce n’est pas vital. Mes concurrents intègrent tous cette fonctionnalité donc il est difficile de rivaliser sans.
• Champ de recherche
  • Could : on peut faire sans, mon blog pourra être correct sans un champ de recherche, mais c’est une fonctionnalité sympa à avoir, elle me permet de concurrencer les bons blogs.

Une notion d’effort

La méthode MoSCoW n’introduit pas vraiment la notion d’effort, celle-ci reste l’apanage d’Agile. Cependant, l’effort nécessaire à chaque fonctionnalité est inconsciemment pris en compte lors de la classification. 

L’effort est une notion abstraite, ce n’est pas une durée, ni une valeur de jours homme. Les points d’effort sont généralement attribués selon la suite de Fibonacci – 0,5, 1, 2 3, 5, 8, 13, etc. – et sont calculés à partir de plusieurs facteurs, notamment la complexité de la fonctionnalité, les inconnues, les risques.

Dans l’exemple présenté ci-avant, l’IA pour recommander les articles est un gros morceau, elle va demander du temps et des capacités. Sans cela, j’aurais peut-être pu hésiter avec un Could. De plus, j’aurais tendance à réserver cette fonctionnalité pour un moment où j’aurai moins de fonctionnalités importantes à réaliser.

Les limites de MoSCoW

Evidemment, la méthode MoSCoW n’est pas parfaite. L’un de ces principaux défauts est de ne pas donner d’indications pour prioriser des tâches de même niveau. D’ailleurs, classer les tâches dans les catégories est également une affaire très subjective, il est souvent difficile de savoir si l’on doit classer une fonctionnalité en Should ou en Could.

Le Won’t est délicat, on ne sait pas vraiment quand la fonctionnalité sera réalisée, si elle est réalisée un jour. Enfin, MoSCoW peut être un piège dans le sens où l’on aura tendance à préférer les nouvelles fonctionnalités à des améliorations techniques moins visibles.

La méthode ToToTo

Une méthode dérivée de MoSCoW existe, nommée ToToTo, pour Today, Tomorrow, Tonight. Dans ToToTo, Today joue le rôle du Must tandis que Tomorrow joue à la fois le rôle de Should et Could, les deux étants difficiles à différencier.

Le Won’t n’existe pas dans ToToTo, Tonight correspond aux fonctionnalités « fun » ou auxquelles on a un attachement particulier, que l’on développerait plutôt sur son temps libre.