Qu'est-ce que la méthode de priorisation Must Should Could Won't ?
Must Should Could Won't, plus connue sous le nom de MoSCoW, répartit le travail en quatre groupes : ce que vous devez faire, ce que vous devriez faire, ce que vous pourriez faire s'il reste du temps, et ce que vous ne ferez pas cette fois-ci. En format rétrospective, elle amène votre équipe à s'accorder à voix haute sur les priorités du prochain sprint ou de la prochaine release, avec tout le monde autour de la table. Dai Clegg a mis au point la méthode chez Oracle dans les années 1990, et elle est devenue un classique de la gestion de projet agile et de l'analyse métier, notamment dans DSDM. Les catégories sont Must have (critique), Should have (important), Could have (souhaitable) et Won't have (pas cette fois). Elle s'intègre bien aux méthodes agiles parce qu'elle place en tête le travail qui a le plus de valeur. Elle offre aussi au product owner une façon structurée de regarder le backlog du point de vue du client : si un client remarquerait son absence au lancement, c'est probablement un Must. La colonne Won't est plus utile qu'elle n'en a l'air. Noter ce que vous avez décidé de ne pas faire l'empêche de revenir discrètement dans le sprint, et indique clairement aux parties prenantes ce qui ne sera pas livré.
Format Must Should Could Won't
Must
Que devons-nous livrer, quoi qu'il arrive ?
Ce sont des exigences non négociables, indispensables à la réussite. Quand vous abordez les éléments « Must », invitez les participants à penser aux vrais points bloquants ou aux éléments essentiels sans lesquels le projet échouerait. Poussez l'équipe à être exigeante sur ce qui mérite d'être un « Must », pour éviter l'inflation des priorités.
Should
Qu'est-ce qui est important sans être critique ?
Ce sont des fonctionnalités ou exigences importantes qui apportent beaucoup de valeur, mais qui ne sont pas indispensables au lancement. Aidez l'équipe à repérer les éléments qu'il serait pénible d'écarter, mais dont l'absence n'empêcherait pas le projet de fonctionner. Concentrez-vous sur ce qui a beaucoup de valeur mais une urgence moindre.
Could
Qu'est-ce qui serait bien si le temps le permet ?
Ce sont des fonctionnalités souhaitables, à réaliser si les ressources le permettent. Aidez l'équipe à trouver les améliorations qui rendraient la solution meilleure sans être essentielles. Ces éléments sont souvent de bons candidats pour de futures itérations ou releases.
Won't
Qu'avons-nous décidé de ne pas faire cette fois ?
Ce sont les éléments que l'équipe décide explicitement d'écarter pour cette itération ou ce projet. Encouragez une discussion honnête sur les fonctionnalités qui pourraient valoir le coup mais ne correspondent pas aux objectifs ou contraintes actuels. Les nommer aide l'équipe à rester concentrée et fixe des attentes claires.
Dans quels cas recourir à cette étude rétrospective ?
- Quand vous lancez un nouveau projet ou une nouvelle initiative et avez besoin de priorités claires
- Pendant l'affinage du backlog, pour trier et prioriser les demandes de fonctionnalités
- Quand les ressources sont limitées et que vous devez faire des choix difficiles sur le périmètre
- En réunion avec les parties prenantes, pour fixer les attentes sur ce qui sera livré et quand
Exemples de questions pour brise-glace
- Quelle est la décision de priorisation la plus difficile que vous ayez dû prendre sur un projet ?
- Si vous ne pouviez livrer que trois fonctionnalités dans votre projet actuel, lesquelles choisiriez-vous et pourquoi ?
Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →
Idées et conseils pour votre réunion de rétrospective
- Limitez les Must à environ 60 % de l'effort total au maximum, comme le recommande DSDM, pour que le plan garde de la marge face aux imprévus
- Revoyez les catégories à mesure que les besoins métier et les contraintes évoluent
- Limitez le temps de discussion de chaque élément pour qu'un seul débat n'accapare pas la réunion
- Notez pourquoi chaque élément a été classé à sa place, pour que le prochain débat ne reparte pas de zéro
- Impliquez les parties prenantes qui portent les exigences, pour que les priorités tiennent dans la durée
- Vérifiez les dépendances avant de classer un élément : un Could dont dépend un Must est en réalité un Must
Foire aux questions
Qu'est-ce que la méthode MoSCoW ?
Que signifient Must, Should, Could et Won't ?
Comment animer une rétrospective MoSCoW ?
Pourquoi l'appelle-t-on MoSCoW ?
Combien d'éléments doivent être des Must ?
Modèles associés
Les quatre questions de Norm Kerth, en partant de la Prime Directive.
Rétrospective Rate of Improvement
Découvrez où les efforts de votre équipe ont vraiment payé.
Rétrospective Quoi ? Et alors ? Et maintenant ?
Passez de ce qui s'est passé à ce que vous allez faire.
Valeurs Scrum
Voyez à quel point votre équipe vit les cinq valeurs Scrum.