Priorisation MoSCoW

J’ai passé la majorité de ma carrière à travailler dans un contexte complexe, selon le Framework Cynefin. Où la priorisation est une obligation, pour diriger le produit ou l’ingénierie.

Et mon goto en priorisation est la méthode MoSCoW, pour assurer l’éfficacité de nos livrables.

Lexique

Commençons par définir quelques termes qu’on va utiliser tout du long, et qui pourraient ếtre ambigues. C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.

• Yak Shaving: littéralement “raser des yaks”, les animaux. Fait référence à une action qui ne résout pas le problème acutelle, mais en conjonction avec d’autres tâches aidera à le résoudre. Plus on en fait, plus on s’éloigne de la résolution du problème principal.

Qu’est-ce que le framework MoSCoW ?

Le nom MoSCoW est un moyen mnémotechnique basé sur quatre catégories de priorité :

• Must have : C’est le coeur de la feature, les éléments essentiels. Sans eux, la livraison n’a pas de sens ou ne seret à rien.
• Should have : Important, mais pas critique. Ces éléments apportent une vraie valeur, mais peuvent être différés temporairement si nécessaire.
• Could have : Des fioritures appréciés mais en aucun cas nécessaires. S’ils sont inclus, tant mieux. Sinon, ils peuvent attendre ou être purgés.
• Won’t have : Ce qui ne sera pas inclus, dont on ne discutera pas. C’est une partie essentielle, et aide non seulement à garder le focus mais aussi à réduire le yak-shaving.

Pourquoi l’utiliser en ingénierie logicielle ?

Pour assurer l’efficacité, se concentrer sur ce qui raporte le plus valeur est une obligation. Le Framework apporte une structure:

• Il clarifie les attentes du livrable
• Force la discussion de la vrai valeur ajoutée de la feature
• Permet de tenir les délais, même en cas d’incident

Une équipe qui produit et doit pouvoir réagir aux incidents de prod, ne peut pas avoir une charge de travail de 100%. Ainsi, il est recommandé de ne pas s’engager sur une date de plus de 2 semaines et représentant plus de 70% de capacité de production.

Les 30% restant servant de tampon lors d’une déviation de production, changement de périmètre, modification de contraintes; On peut ainsi garantir la date de livraison malgré tout.

Il est recommandé que:

• Les Must doivent pas représenter plus de 30% de la capacité de production
• Les should ne devrait pas représenter plus de 30% de la capacité de production.
• On s’engage à livrer uniquement les Must de manière certaine, et de faire au mieux pour essayer de livrer les should.

Exemple : refonte d’une API publique

Imaginons que notre équipe doive refondre une API utilisée par des intégrateurs externes. Voici une priorisation possible avec MoSCoW :

Must

• Compatibilité ascendante avec l’existant
• Authentification sécurisée (JWT)
• Documentation minimale versionnée
• Réponse en moins de 500ms (95 percentile)

Should

• Gestion de la cache
• Dashboard d’usage minimal pour les partenaires
• Gestion de rate-limiting par consommateur

Could have

• SDKs clients dans 3 langages
• Mode sandbox de test

Won’t have

• Interface graphique d’exploration de la donnée
• Analytics avancés
• Objets dans la base de données

Ainsi l’équipe s’engagera uniquement à livrer les 4 attributs en Must dans la cadence. On pense pouvoir livrer facilement les attributs en should. On espère pouvoir livrer les attributs en Could, mais ce n’est pas grave. Dans une autre itération, nous allons travailler la représentation en base de donnée, les analytics et une interface étendu.

Quelques conseils et limites

La problèmatique principale est: Qu’est qui est Core Feature. On fini souvent avec trop. Et c’est souvent relié au manque de donnée/visibilité du Business. Ainsi bien définir l’objection de l’initiative est nécessaire. Et souvenait vous, il n’existe que 3 objectifs business: acquisition de client, retention de clients/croissance chez le client, réduction de coûts opérations. Pour ma part, j’enlève jusqu’à ce que l’initiative ne fasse plus sense, ou ne puisse plus délivrer la valeur voulue.

Le framework sert à priorisé: priorisé veut dire faire du triage. Certaines tâches pourront pas être sauvées. Du coup, fait le. Vous pouvez faire varier les priorité durant la cadence. Ainsi au début seule une tâche sera en must, puis deux, trois, etc.

C’est un artefact pour structurer la collaboration. Du coup, on discute et on priorise!

Utilisez-le dans vos RFCs, tickets ou plannings. Cela apporte une transparence naturelle.

En conclusion

MoSCoW donne une structure pour la priorisation. Il fera aussi resortir d’autre manquement (très souvent relié à la définition business). L’artefact permet de discuter plus saine de ce qu’est la Core Feature et de la priorisation, pour toujours garder à l’esprit le vrai but de l’initiative: L’Objectif business/La valleur ajoutée, et non la complétude des tâches.