La priorisation MoSCoW classe les exigences en quatre groupes : Must Have, Should Have, Could Have et Won’t Have pour cette version.
Les étiquettes sont simples. Les utiliser honnêtement est plus difficile, surtout lorsque chacun possède sa propre vision de la première version. Pour un MVP, MoSCoW aide l’équipe à protéger le parcours utilisateur principal et à écarter les fonctionnalités qui peuvent attendre.
Commencez par le résultat, pas par la liste de fonctionnalités
Avant de trier le backlog, écrivez ce que le MVP doit prouver :
Nous pensons que [audience précise] utilisera [solution] pour obtenir [résultat utile]. Nous considérerons cette hypothèse validée lorsque [comportement mesurable] se produira.
Par exemple :
Nous pensons que les petites entreprises de services utiliseront un outil de réservation en ligne pour permettre à leurs clients de prendre rendez-vous sans appeler. Nous considérerons cette hypothèse validée lorsque 20 entreprises auront reçu des réservations finalisées.
L’équipe dispose maintenant d’un critère concret. Une fonctionnalité mérite sa place lorsqu’elle contribue au résultat, teste l’hypothèse, répond à une vraie contrainte ou collecte les preuves nécessaires à la prochaine décision. « Un concurrent la propose » ne suffit pas.
Définissez un parcours utilisateur complet
Cartographiez ensuite un chemin complet de l’entrée jusqu’à la valeur. Pour un produit de réservation, il pourrait être :
L’entreprise crée ses disponibilités → le client choisit un horaire → la réservation est confirmée → l’entreprise voit la réservation.
La première version n’a pas besoin de toutes les règles de planification ni de toutes les intégrations calendrier. Elle doit en revanche rendre ce parcours fiable. Un petit périmètre convient. Un parcours cassé, non.
Classez chaque exigence
Must Have
Un Must Have est indispensable à la version. Sans lui, le parcours principal échoue, l’hypothèse ne peut pas être testée ou le produit devient dangereux ou inutilisable.
Le meilleur test est direct : annulerions-nous ou reporterions-nous le lancement si cet élément manquait ?
Pour le produit de réservation, cela peut inclure l’affichage des créneaux, l’envoi d’une réservation, la prévention des doubles réservations et la visibilité du résultat pour l’entreprise. Une confirmation simple peut aussi être nécessaire. Un modèle d’e-mail personnalisé à la marque ne l’est pas.
Si une solution temporaire existe, même manuelle et peu élégante, l’exigence appartient probablement à Should ou Could.
Should Have
Un Should Have est important, mais les utilisateurs peuvent toujours terminer le parcours principal sans lui. Son absence peut créer du travail supplémentaire ou une expérience moins fluide.
Les liens d’annulation, rappels, reports simples, rapports hebdomadaires et exports calendrier peuvent entrer dans cette catégorie. Gérer les annulations manuellement est peu pratique, mais l’équipe peut toujours vérifier si les entreprises veulent réserver en ligne.
Could Have
Un Could Have améliore le produit sans changer ce que le MVP peut prouver : couleurs personnalisées, mode sombre, rapports avancés ou intégration avec un calendrier supplémentaire.
Ces éléments donnent de la souplesse au plan. Si le temps manque, ils partent en premier. Le délai et la qualité fondamentale du produit ne doivent pas dépendre d’eux.
Won’t Have pour cette version
Won’t Have signifie « pas dans cette version », et non « jamais ». Applications natives, paiements intégrés, gestion de plusieurs sites, planification par IA ou marque blanche peuvent tous se trouver ici.
Consignez la raison de chaque décision. Sinon, les mêmes idées réapparaîtront au milieu du développement sans que personne ne se souvienne de leur exclusion.
Remettez en question chaque Must proposé
C’est souvent ici que MoSCoW échoue. Tout ce qui paraît important devient un Must et le MVP redevient discrètement le produit complet. Interrogez chaque Must :
- Le parcours principal échoue-t-il sans lui ou devient-il seulement moins pratique ?
- Arrêterions-nous réellement le lancement ?
- Un tableur, un ticket de support ou une validation manuelle pourrait-il le remplacer temporairement ?
- Aide-t-il à produire ou à mesurer l’hypothèse ?
- Peut-il être réduit à une capacité plus petite ?
- En avons-nous besoin maintenant ou dans une version ultérieure ?
Les noms généraux comme « analytics » ou « authentification » compliquent l’exercice. Décomposez-les en actions précises que l’utilisateur ou le système doit pouvoir réaliser. Enregistrer une réservation terminée peut être un Must. Un tableau de bord analytics complet peut attendre.
Priorisez l’effort, pas le nombre de fonctionnalités
Le nombre de fonctionnalités indique peu de choses sur le risque de livraison. Dix petits Must peuvent demander moins de travail qu’une intégration complexe : comparez donc l’effort plutôt que le nombre de cartes.
Les recommandations DSDM suggèrent de limiter les Must à environ 60 % de l’effort disponible. Considérez ce chiffre comme un signal d’alerte, pas comme une loi mathématique. Si les Must remplissent tout le calendrier, le plan suppose que chaque estimation sera exacte et qu’aucun imprévu ne surviendra.
Ajoutez des preuves et organisez un atelier ciblé
MoSCoW devient un exercice politique lorsque les priorités dépendent de la personne qui argumente le plus fort. Chaque exigence doit être accompagnée d’une courte justification : entretien client, processus observé, réglementation, dépendance technique ou test d’utilisabilité.
Pendant l’atelier, rappelez l’hypothèse, la date limite et la capacité disponible. Cartographiez le plus petit parcours complet, puis placez d’abord toutes les exigences dans Won’t Have. Ne les remontez que lorsqu’une personne peut expliquer pourquoi elles méritent leur place.
Avant de conclure, remettez encore en question la liste des Must et estimez l’effort qu’elle représente. Consignez les décisions. Une personne doit garder la responsabilité finale du périmètre lorsque le groupe ne parvient pas à s’accorder.
Réexaminez les priorités pendant la livraison
Les priorités évolueront. Revoyez-les lorsqu’une estimation change, qu’une recherche invalide une hypothèse ou que l’équipe découvre une dépendance.
N’ajoutez pas de nouveau Must sans supprimer, réduire ou reclasser un autre élément. Après le lancement, appuyez-vous sur les usages réels. Un Should peut devenir Must parce que les utilisateurs restent bloqués. Une fonctionnalité jugée importante peut passer en Won’t parce que personne ne la demande.
Un MVP ciblé produit un résultat utile et fournit à l’équipe les preuves nécessaires à la prochaine décision. Tout le reste peut attendre que les utilisateurs donnent une raison de le construire.
Si votre équipe n’arrive pas à définir le périmètre de la première version, nous pouvons le cadrer avec vous puis le porter jusqu’au design et au développement. Découvrez l’approche MVP de One Peak.