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.

• 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.