La méthode MoSCoW pour prioriser ton backlog
Ton backlog produit contient des centaines de lignes et tu n'as pas le temps ni l'énergie de les prioriser ? Mettons un peu d'ordre et de pertinence rapidement avec la méthode MoSCoW.
Bonjour,
J’espère que tu es en pleine forme !
Au moment où tu reçois cette newsletter, je suis en Corée du Sud à Jeju, donc si je ne te réponds pas tout de suite c’est normal, je serai de retour début avril. 🏝️😎🍹
Si tu penses qu’une personne autour de toi pourrait être intéressée par Product Shonen, n’hésite pas à lui transférer cette édition directement par e-mail, ou à cliquer sur le bouton ci-dessous !
Si tu n’es pas encore abonné(e), c’est le moment 👇
🗺️ Le plan
La méthode MoSCoW
Qu’est-ce que cela signifie ?
M pour “Must have this”
S pour "Should have this"
C pour "Could have this"
W pour "Won't have this"
En pratique
Alternative : La matrice d'Eisenhower
Suite à la méthode de priorisation RICE, je voulais te parler de la méthode MoSCoW.
Créée par Dai Clegg (un vétéran d’Oracle) en 1994, cette dernière est plus simple à mettre en place que la méthode RICE.
Elle n'apporte pas d'échelle précise sur la priorité mais lorsque le temps est limité, et que tu souhaites dégrossir ton backlog product, c'est selon moi une bonne alternative.
Je parlerai ici souvent du backlog product mais ça peut aussi s’appliquer à d’autres échelles comme la priorisation des users stories.
La Methode MoSCoW
Que signifie MoSCoW ?
Tu l’auras compris, on ne parle pas ici de Moscou en Russie mais c'est un moyen mnémotechnique pour se rappeler des 4 catégories.
En réalité, seules les lettres MSCW comptent.
Afin de gagner du temps lors de ce filtrage, il faut que toutes les parties prenantes se mettent d'accord sur les objectifs et les facteurs de priorisation des tâches.
M pour "Must have this" (Vital)
Tâches obligatoires à exécuter en priorité absolue
C'est ce que l'on doit impérativement avoir/réussir dans le produit.
C'est une initiative vitale, impossible à contourner, cela fait partie des fondamentaux non négociables à effectuer. 🙅
Sinon, le projet risquera fortement d'échouer.
Pour savoir si dans ton backlog product tu dois taguer une ligne comme "Must have this", tu peux te poser les questions suivantes :
La feature se réalisera-t-elle en cas d'absence de cet élément ?
Y a-t-il une alternative ?
Que se passera-t-il si je n'ajoute pas cela ?
Exemples
Dans les exemples qui vont suivre, je partirai du principe que l'on souhaite créer un site e-commerce from scratch.
Avoir une page avec les articles
Avoir un moyen de payer un article
S pour "Should have this" (Essentiel)
Valeurs ajoutées aux "Must have" pour les finaliser
C'est ce qui devrait être réalisé si possible.
La priorité est moindre que les "Must have", ce sont des initiatives à prendre en compte après.
Cependant, elles restent tout de même importantes, car elles apportent une vraie valeur ajoutée au produit et t’aident à atteindre tes objectifs fixés.
Exemples
Une page d'accueil
Une page produit
Un panier
C pour "Could have this" (Confort)
La cerise sur le gâteau 🍒
Après les "Must have" et les "Should have", nous avons les "Could have" qui sont des tâches optionnelles.
On pourrait appeler ça aussi des "Nice to have", ils permettent d'ajouter de l'élégance à ton produit mais n'affectent pas les fonctionnalités déjà en place.
Cela rendra la navigation plus agréable pour l'utilisateur.
C'est comme pimpé ta caisse avec un aileron, ajouter des LEDs partout dans ton bureau ou avoir un Macbook pro m2 16Go de RAM alors que tu es sur Notion toute la journée. 😛
Exemples
E-mail automatique pour tracker la commande
Ajouter des avis sur les articles
Avoir un compte client
W pour "Won't have this" (Luxe)
À laisser de côté pour l’instant
Dans cette catégorie, ce sont des initiatives qui seraient bien à avoir mais pas dans l'immédiat.
C'est du luxe, en termes de ressources.
Elles peuvent être reconduites plus tard mais il faudra faire sans.
Exemples
Avoir une app mobile
Refonte complète du design
Système de point de fidélité
En pratique
Aide-toi d'un Figjam, d’un Notion ou d'un tableau Kanban, et pendant la priorisation, fais attention à tes envies et aux envies de l'équipe.
Un élan émotionnel peut fausser la catégorisation, essaie de rester objectif pour éviter les biais cognitifs.
Croise aussi le tout avec tes OKRs. Cela te permettra d’être sûr que tu crées de la valeur pour les utilisateurs mais aussi pour ton entreprise (voir l’article sur les OKRs)
Voici également quelques templates que tu peux utiliser pour prioriser :
La matrice d'Eisenhower
C'est une alternative qui peut aussi t’aider à prioriser des tâches lorsque tu es submergé de choses à faire.
Elle prend en compte l'importance et l'urgence :
Important et Urgent → Je dois le faire maintenant
Important et Non Urgent → Je dois le planifier (et le faire plus tard)
Non Important et Urgent → Je peux déléguer ou renégocier/revoir le projet
Non Important et Non Urgent → Je n’en tiens pas compte, c’est ciao ! 🚮
Voilà, j’espère que cette méthode de priorisation va t’aider autant que la méthode RICE !
La semaine prochaine, je vais te parler de la méthode de priorisation Kano, après j’arrête. On parlera de Roadmap, design thinking, design sprint…
Bonne fin de semaine, ✨
Kevin ❤️
Tu aimes la newsletter Product Shōnen, pourquoi ne pas la partager à tes proches ?