Comment je priorise ma backlog ?
Comme vous le savez, la priorisation des fonctionnalités par la valeur business est indispensable pour que l’équipe s’organise, se concentre sur les sujets à plus forte valeur ajoutée et délivre au plus tôt, afin d’avoir un feedback utilisateur pour s’adapter lors de la prochaine version et un début de retour sur investissement, plutôt que d’attendre l’ensemble des besoins identifiés et maturés pour commencer les développements.
Nous allons vous proposer quelques modèles qui vous seront utiles pour factualiser la priorisation des fonctionnalités avec votre Métier.
Rappelez-vous que quel que soit le modèle choisi, il sert surtout d’excuse pour collaborer, discuter et se mettre d’accord.
Le modèle le plus basique : MoSCow
MoSCoW est un acronyme destiné à fournir un moyen mnémotechnique de retenir les 4 catégories de priorisation.
- Must have [Vital] : Doit être fait. On ne peut implémenter la solution sans cette fonctionnalité,
- Should have [Essentiel] : Devra être fait dans la mesure du possible. Cela peut être “douloureux” de laisser de côté cette fonctionnalité, mais la solution est toujours viable,
- Could have [Confort] : Pourrait être fait dans la mesure où cela n’impacte pas les autres fonctionnalités,
- Won’t have [Luxe] : Ne sera pas fait cette fois, mais sera fait plus tard.
Et les “o” de MoSCoW, ils servent à quoi ? Ils ont été ajoutés uniquement pour nous aider à nous souvenir de la méthode et des 4 lettres principales.
Ses avantages
Il s’agit d’une méthode de priorisation simple et rapide à utiliser avec votre Métier.
Ses limites
Il faut avoir peu de métiers car sinon chacun renchérira sur l’autre en pensant que son besoin est plus important et vous n’aurez pas d’indication pour connaitre la réelle priorité des sujets.
Les participants de l’atelier risquent de tomber dans le piège du « tout est important ». Du fait de leurs expériences passées, ils vont considérer que les sujets en “Could have” ou “Won’t have” ne seront jamais réalisées par les équipes de développement. Aussi, ils placeront tout dans un niveau supérieur. Aussi, il est nécessaire d’avoir un bon état d’esprit et de comprendre les règles pour utiliser cette méthode.
Le modèle Kano
Le diagramme de Kano est un outil d’analyse du besoin qui met en perspective le niveau de satisfaction de vos clients par rapport aux fonctions du produit que vous leur proposez.
4 courbes dans ce diagramme :
- Indispensables : Une fonctionnalité considérée comme basique. Il est implicite qu’elle soit présente,
- Indifférents : Une fonctionnalité qui laisse indifférent si elle existe ou non,
- Proportionnels : Une fonctionnalité que l’on peut caractériser comme attendue. Elle satisfait si elle est présente et insatisfait si elle est absente,
- Attractifs : L’absence de la fonctionnalité n’entraîne pas d’insatisfaction, mais sa présence en revanche génère une satisfaction plus que proportionnelle.
Avant de démarrer, il est intéressant de se poser ce type de questions :
Question 1 : Si votre [produit/service] permet de [fonctionnalité du produit] …
Question 2 : Si votre [produit/service] ne permet pas de [fonctionnalité du produit] …
Avec le choix d’une réponse sur les 5 suivantes :
- ça me plaît
- je trouve ça normal
- ça m’est égal
- je m’en contente
- ça me déplaît
Vous obtiendrez la matrice suivante :
Ses avantages
Cela permet d’avoir une vision claire de ce que pense votre Métier, avec une identification efficace et facile des besoins. Ce modèle peut être appliqué à n’importe quel stade du cycle de vie de chaque produit.
⚠️ Il sera essentiel dans votre Delivery d’avoir les 4 courbes pour mettre à disposition et équilibrer aussi bien l’effet Waouh que l’indispensable (pour gérer régulièrement la dette technique).
Ses limites
Si de nombreuses fonctionnalités doivent être testées, les enquêtes deviennent parfois très longues et fatigantes pour les personnes interrogées.
Le modèle ROI
Il s’agit d’une priorisation avec la business value. Ce type de va nous permettre de chiffrer cette valeur et de la mettre en rapport avec l’effort de mise en oeuvre.
Lors d’un atelier de priorisation, vous réunirez ses Métiers (ou leurs représentants) et leur présenter une sélection de fonctionnalités à prioriser. A l’aide de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21) chaque participant va attribuer une valeur à chacune des fonctionnalités. Ce sera la valeur business (ou Business Value). Après débat et affinage lors d’un deuxième tour, s’il existe toujours une disparité dans les notes, on calcule alors la moyenne. Puis, vous demanderez à votre équipe de définir l’effort de réalisation de la fonctionnalité (en Storypoint, par exemple, qui peut être défini par la suite de Fibonacci), pour permettre de calculer le ROI.
Ses avantages
Faire passer des fonctionnalités avec un fort ROI peut être intéressant, car elles sont en général rapides à traiter et leur valeur business est forte (et donc intéressante pour votre Métier).
Ses limites
L’ensemble des métiers risquent de mettre une Business Value forte sur leurs fonctionnalités en croyant qu’ils passeront avant les autres. D’autre part, concernant la suite de Fibonacci, restons simples. Limitez-vous à 1, 2, 3, 5 et 8 … voire 13 car l’intérêt n’est pas dans le détail et la précision, mais plutôt de savoir si la fonctionnalité est simple, moyenne ou complexe.
“En fournissant des estimations inexactes pour de très grandes choses, les équipes/propriétaires de produits/parties prenantes peuvent avoir un faux sentiment de sécurité quant à l’effort qui sera nécessaire.” — Mike Cohn dans son livre “Agile Estimating and Planning”.
Pour aller plus loin concernant la suite de Fibonacci : Cult Of Fibonacci — The Seattle Scrum Company
Le modèle WSJF
Le modèle Weighted Shortest Job First (ou en français : “La plus importante ou la plus courte fonctionnalité en premier”) est basé sur le modèle ROI, en y ajoutant la notion de “coût du délai”, à savoir l’impact qu’aura le temps sur le coût de chaque fonctionnalité. Car ce modèle part du principe que toute fonctionnalité non livrée à temps à un coût.
Plus le WSJF a une valeur importante, plus la fonctionnalité pourra être priorisée. D’autre part, cela permet de mettre en évidence que :
- Plus les fonctionnalités (Minimum Marketable Feature ou MMF) sont petites, plus elles sont faciles à estimer les unes des autres,
- Une fonctionnalité semble importante, ce n’est pas pour cela qu’elle sera obligatoirement priorisée puisque d’autres facteurs interviennent dans le calcul,
- Cela permet de voir l’impact si le fonctionnalité n’est pas développée à court terme.
Il est important de souligner que ce calcul n’est pas figé dans le temps, il faudra donc le réviser régulièrement avec votre Métier.
Exemple : la priorité la plus forte est de 5,50. C’est donc ce sujet qui serait à prioriser.
Ses avantages
Très pratique lorsque vous avez différents métiers, en permettant à chacun d’ajouter des axes importants pour eux (risque, urgence …) et qui seront définis à l’aide de la suite de Fibonacci (1, 2, 3, 5, 8, 13). L’autre intérêt est que les équipes de réalisation (développeurs et testeurs) ont aussi leur mot à dire car la notion d’effort influe sur la priorisation.
Ses limites
Il faut éviter d’ajouter trop d’axes pour éviter de passer trop de temps à faire des estimations. Réfléchissez aux axes essentiels avec votre Métier avant de vous lancer dans un atelier de priorisation avec eux. Comme pour le ROI, pour la suite de Fibonacci, limitez-vous à 1, 2, 3, 5 et 8 … voire 13.
N’hésitez pas à ajouter une colonne commentaire, pour historiser vos discussions avec le Métier, vos hypothèses. Quelques semaines plus tard, vous avez un doute sur le pourquoi nous avons priorisé un sujet plutôt qu’un autre ? Vous pourrez consulter votre WSJF !
Il existe d’autres modèles de priorisation
Sachez que d’autres types de priorisation existent, n’hésitez pas aussi à les regarder et à tester pour trouver le modèle le plus approprié à votre équipe.
Eisenhower Matrix. This model was designed in 34th… | by Muhammad Zubair Ashraf | Medium
