Cet article est composé de plusieurs parties, si vous arrivez depuis la 1ère partie de cet article, merci de nous avoir suivi jusqu’ici. Sinon vous pouvez également retrouver ici notre première partie Part 1 – Comment choisir son framework de priorisation parmi 9 méthodes pour vous aider à orienter votre choix et votre approche de priorisation du backlog produit.
On commence notre deuxième partie de l’article des méthodes de priorisation avec des approches qui seront plutôt simples. Elles conviendront parfaitement si vous n’avez pas nécessairement accès à beaucoup de data ou si votre temps est compté. Elles vous permettront de prendre rapidement des décisions seul ou avec votre équipe.
Si vous recherchez des approches plus avancées, travaillées avec de la data et des modèles plus complexes, nous vous invitons à passer directement à la troisième partie.
Pour rappel, nous verrons ici les frameworks suivants :
Valeur vs Complexité
Matrix d’Eisenhower
Kano
MoSCoW
Une manière très simple de comparer deux aspects d’une feature. D’une part la valeur qu’elle apporte à l’entreprise ou à nos utilisateurs et de l’autre l’effort ou la complexité pour l’équipe de réalisation (on peut inclure les efforts de la conception design au développement).
On va tout simplement donner une note de valeur et de complexité aux features puis les placer sur le graphique suivant. Selon la zone dans laquelle tombe le point nous permettra de la classer.
Quicks wins : Forte valeur / Peu d’effortInitiatives stratégiques : Forte valeur / Effort important
Efforts simples : Faible valeur / Faible effort
Les features à déprioriser ou abandonner : Faible valeur / Effort important
Idéale pour une priorisation rapidePermet d’identifier facilement des “quick-wins”
Identifie les features complexes à découper
Peut aider à la définition de valeur et de complexité dans une organisation
La valeur et la complexité peuvent avoir de multiples facettesOn reste sur de l’estimation, qui induit forcément des biais cognitifs
Plus difficile à maîtriser dans des environnements larges et complexes
Un second modèle avec une approche plutôt simple. Le focus ici est mis sur l’urgence et l’importance. Elle permet d’écarter les sujets peu importants et ceux à réaliser immédiatement.
Chacune des tâches sera classée dans la catégorie urgente ou non urgente et dans la catégorie important et non important. Il sera ensuite facile de classer les tâches dans la bonne case ci-dessous. C’est un excellent outil pour gérer ses priorités au quotidien comme sa todo du jour.
A faire maintenant : Important et urgentA faire plus tard : Important mais non urgent
A déléguer : Urgent mais non important
A abandonner : Ni urgent ni important
Pratique pour une priorisation rapidePermet aussi d’identifier ce qui peut être décidé plus tard ou délégué à une autre entité/personne
Décisions peuvent être prise dans un atelier très simple
Une approche assez subjective qui laisse libre court à l’approche de chacunUrgent peut avoir plusieurs définitions, de prioritaire à l’urgence temporelle
Si trop d’éléments sont dans la catégorie A faire maintenant, la priorisation sera peu effective
Un modèle de satisfaction client créé par le professeur Noriaki Kano en 1980 que j’ai découvert dans le Lean Product Playbook. Il compare la satisfaction et la performance via 3 types de features dans cette approche.
Must have : Si elles ne sont pas présentes l’insatisfaction est grande mais lorsqu’elles le sont elle n’en apportent que très peu
Performance : Mieux elles sont servies/plus il y en a, mieux elles sont perçues
Delighters : Vos utilisateurs ne les attendent pas vraiment, mais lorsqu’elles sont présentes elles vous donnent un vrai coup d’avance.
Pratique pour une approche qualitative sans avoir de donnéesOutil visuel très facile à comprendre
Permet de classer facilement des fonctionnalité dans 3 types de besoins
Ne tient absolument pas compte de l’effortNi de la valeur business pour une entreprise
L’approche par la méthode MoSCoW permet de classifier les features dans 4 catégories :
Must have : obligatoires et non-négociables
Should have : importantes non-vitales mais apportent de la valeur significative
Could have : ou Nice to have qui n’auront qu’un impact faible si elles sont oubliées
Will not have : celles qui ne sont pas important à l’heure actuelle
Pratique pour inclure des stakeholders sans connaissance technique dans la priorisationRapide, intuitif pour communiquer les priorités
Pour des ateliers à monter rapidement, tout le monde comprends les 4 catégories tout de suite
Les fonctionnalités must-haves finissent par être souvent très nombreusesOn est plutôt sur un exercice de critères de release pour un MVP que sur une méthode de priorisation
Après avoir découvert les méthodes dont l’approche était plus simple, nous allons aborder des frameworks plus avancés. Dans notre troisième partie nous aborderons des méthodes de priorisation qui demandent plus de temps de préparation, plus de data et peuvent inclure des parties externes.
Passez tout de suite à nos approches de priorisation avancées ou revenez à notre première partie pour quelques conseils sur vos choix de frameworks.