J'ai été amené récemment à assister un Product Owner à préparer une réunion de priorisation de backlog (outre la personne en question, à la réunion y assistaient trois autres pour leur première priorisation de ce type). Deux façons se présentaient à nous: prioriser sur 100 points ou démarrer par une priorisation MoSCoW.

Pour rappel MoSCoW est un acronyme et permet de découper les priorités en 4 parties:

Must have: Priorité maximale pour un besoin ou une fonctionnalité absolument indispensable sans quoi le produit est inutile

Should have: La fonctionnalité a une très haute valeur ajoutée et doit absolument être incluse si le temps le permet. Cependant, si ce n'est pas le cas, on peut répondre au besoin d'une autre façon

Could have: Le petit plus Periglioni comme dirait Elie Semoun, le besoin n'est pas absolument nécessaire mais n'est pas négligeable car il peut permettre de faire la différence.

Won't have but Would have: La réponse à ce besoin est pour le moment hautement secondaire et ne doit pas passer avant le reste (la fonctionnalité n’est pas à développer dès la première itération).

Nous avons donc décidé de commencer par MoSCoW quitte à affiner avec la méthode des 100 points. Pourquoi ? Parce qu’il est difficile de prioriser d’autant plus lorsqu’on est nombreux. On limite le nombre de possibilités offertes. Au lieu d’avoir 100 possibilités, on en a 4 ce qui restreint les ardeurs des plus pointilleux d’entre nous.
Le but de la manœuvre est qu’une fois qu’on a fourni nos priorités sur 4, on peut définir des fourchettes sur 100.

La plupart du temps, en MoSCoW les hésitations se feront sur les combinaisons Must/Should ou Should/Could et Could/Would, peu de chance d’avoir une hésitation sur Must/Could (et sur une hésitation Must/Would… on ne sait jamais mais quand même…)

Quelles questions se poser lorsqu’on hésite entre deux priorités ?

Must/Should : Une des premières questions à se poser est « A quel point, le client a mis en avant cette fonctionnalité? », quel est le niveau d’importance pour le client.
Nous savons que la plupart du temps ce dernier mettra une grande partie des fonctionnalités au niveau d’importance le plus haut mais il est assez facile de dégager quel est le point névralgique, ce autour de quoi tourne le projet, si la fonctionnalité est au centre c’est bien sur un Must.
Si ce n’est pas le cas mais qu’un doute persiste, on peut se demander « est-ce que cette fonctionnalité peut être remplacée par une version plus légère dans un premier temps? ». Si la réponse est non c’est un Must, si oui un Could.
Le besoin du client peut être très précis et amener à des choses compliquées à développer. Ces éléments peuvent parfois être simplifiés dans un premier temps (pour un site de restauration, l’utilisation d’un google map interactif pour situer un lieu pourra être remplacé par une image dans un premier temps)

Should/Could : Plus difficile, il faut là savoir si ce besoin est primordial pour le business « que se passerait-il si on ne mettait ça pas en place ? ». S’il a été décidé que la fonctionnalité n’était définitivement pas un Must mais que le fait de ne pas la développer pourrait handicaper le chiffre d’affaire ou l’image du produit c’est que c’est un Should. Si par contre, ce développement permet une amélioration et que son « non-développement » n’est pas impactant, c’est que c’est un Could (ajouter un google map permet mieux situer un lieu en regardant l’espace alentour mais mettre une image avec l’adresse n’empêchera pas aux utilisateurs de trouver le lieu).

Could/Would : Comme l’a très bien posé le Product Owner durant la réunion « si on n’a pas le temps de tout faire, quel serait l’impact si on faisait ce développement par rapport à celui-là (précédemment priorisé en Could) ? ». La réponse a été vite vue, « Would » tous en cœur (en l’occurrence, le « Would » en question était un gadget graphique mais pouvait être estimé utile, d’où l’hésitation).

Il peut être assez simple de débloquer des situations avec les bonnes questions, le fait de n’avoir que 4 possibilités est aussi un atout pour accélérer les décisions.

Après ce découpage, la possibilité offerte est d'apposer aux 4 priorisations une fourchette sur la base 100.

Un exemple simple mais ensuite à vous de voir :

20 items en tout:

• Priorisation MoSCoW
  • 5 items en Must
  • 8 items en Should
  • 4 items en Could
  • 3 items en Would

• Découpage sur 100 points
  • Must => 75 à 100
  • Should => 50 à 75
  • Could => 25 à 50
  • Would => 0 à 25

On limite ainsi le champ des possibles, 5 items à répartir sur 25 points est plus rapide et moins imposant que de tout faire d’un coup sur 100

Petit bonus pour la détente (et mine de rien, bon moyen de ne pas oublier la méthode)
Dschinghis Khan - Moskau