Priorisez vos fonctionnalités avec MoSCoW
Vous brainstormez pour votre app de streaming et vous obtenez beaucoup idées géniales :
Lecture vidéo
Inscription utilisateur
Partage sur Facebook
Mode nuit
Sous-titres
Chromecast
Recommandations
Chat en direct
Mode hors-ligne
etc.
Par quoi commencer ? Tout faire en même temps est impossible ! Vous allez donc devoir prioriser les fonctionnalités.
La méthode MoSCoW
On a vu avec la méthode T-shirt comment estimer la complexité et l’effort des différentes User Stories. C’est une étape essentielle : elle permet de savoir ce qui est petit, moyen ou gros, et d’anticiper la charge de travail. Mais estimer ne suffit pas ! Certaines fonctionnalités très complexes (taille L ou XL) sont indispensables, tandis que d’autres, faciles à faire (XS ou S), peuvent apporter peu de valeur.
Must Have
Sans ces fonctionnalités, le produit n'a aucune valeur ou ne peut pas exister.
Pour identifier les Must Have, posez vous les questions suivantes :
Sans cette fonction, l'app aurait-elle encore un sens ?
Le client paierait-il pour un produit sans ça ?
Est-ce légalement/techniquement obligatoire ?
Should Have
Ces fonctionnalités améliorent significativement l'expérience mais ne sont pas bloquantes.
Pour identifier les Should Have, posez vous les questions suivantes :
Cette fonction améliore-t-elle clairement l'expérience ?
Son absence serait-elle remarquée par les utilisateurs ?
A-t-elle un impact sur la satisfaction client ?
Could Have
Ces fonctionnalités "nice-to-have" ajoutent de la valeur mais ne sont pas prioritaires.
Pour identifier les Could Have, posez vous les questions suivantes :
C'est cool, mais est-ce que ça change vraiment la donne ?
Les utilisateurs le demanderaient-ils spontanément ?
Quel est l'impact si on ne le fait jamais ?
Won't Have
Ces fonctionnalités sont explicitement exclues de la version développée mais potentiellement intéressantes plus tard.
Il est important de lister les "Won't" car cela :
évite les malentendus avec le client,
permet de dire "oui, mais plus tard",
garde une trace des idées pour les futures versions.
Concrètement, ça donnerait quoi pour notre application de streaming vidéo ?
Must Have - Lire une vidéo : C'est la valeur métier principale
Should Have - Mode plein écran : Améliore l'expérience de visionnage
Could Have - Notation des vidéos (5 étoiles) : Engagement communauté
Won't Have - Recommandations personnalisées IA : Trop complexe techniquement pour le MVP (Minimum Viable Product)
Erreurs fréquentes avec MoSCoW
Même si la méthode MoSCoW est simple et efficace, certaines mauvaises pratiques peuvent en réduire fortement l’impact. Voici les erreurs les plus courantes à éviter :
Trop de "Must Have" : Si 80% des fonctionnalités sont "Must", la priorisation ne sert à rien ! Demandez-vous : "Le produit peut-il exister sans ça ?". Vos Must Have devraient représenter 20-30% du backlog total maximum.
Négliger les "Should Have" : Se contenter des Must Have donne un produit trop basique. Les Should Have font la différence concurrentielle !
Pas de révision des priorités : Les priorités évoluent selon les retours utilisateurs. Re-priorisez avec MoSCoW après chaque Sprint Review.
À vous de jouer
Contexte
Votre travail de développement sur l’application de streaming n’est pas terminé.
Aujourd’hui, l’objectif est de définir un MVP c’est-à-dire une première version fonctionnelle minimale à lancer rapidement sur le marché.
Consignes
Classez ces 10 fonctionnalités en utilisant la méthode MoSCoW.
Créer des playlists
Écouter une musique
Mode hors-ligne (téléchargement)
Paroles synchronisées
Découverte musicale (recommandations)
Partage de playlist
Égaliseur audio
S'inscrire/Se connecter
Recherche d'artistes/albums
Mode podcast
Livrable
En résumé
La méthode MoSCoW classe les exigences en 4 catégories : Must Have (indispensable), Should Have (important), Could Have (optionnel), Won't Have (pas cette fois).
Les Must Have représentent maximum 20-30% du backlog total pour éviter une fausse priorisation.
L’exigence Won’t Have permet de dire "oui, mais plus tard" et garde une trace des idées pour les versions futures.
Les priorités doivent être révisées après chaque Sprint Review selon les retours utilisateurs.
Avec des User Stories estimées et priorisées, il ne reste plus qu'à structurer le tout dans un Product Backlog vivant.
