Bonjour !
Dans la leçon précédente, nous avons appris à rédiger des User Stories claires et concises, accompagnées de leurs critères d'acceptation. Votre Product Backlog commence donc à se remplir d'éléments qui représentent de la valeur pour vos utilisateurs. Cependant, un backlog peut vite devenir une très longue liste de souhaits. La question cruciale est donc : par où commencer ?
C'est là qu'intervient la priorisation. L'objectif de cette leçon est d'apprendre à appliquer une technique de priorisation du Product Backlog, en nous concentrant sur deux approches très répandues et pratiques : la méthode MoSCoW et la matrice Valeur vs. Effort.
Pour vous qui visez un rôle de Tech Lead ou de Product Owner, savoir prioriser est une compétence absolument fondamentale. C'est à ce moment que vous passez de la simple collecte de besoins à la prise de décision stratégique. C'est l'art de guider l'équipe pour qu'elle construise la bonne chose, au bon moment, afin de maximiser l'impact du produit tout en gérant les contraintes de temps et de budget.
1. Pourquoi la priorisation est-elle cruciale en agilité ?
Avant de plonger dans les techniques, il est essentiel de comprendre pourquoi la priorisation est au cœur de la gestion de projet agile, et notamment de Scrum.
- Ressources limitées : Aucune équipe ne dispose de temps, de budget ou de personnel illimités. La priorisation permet de s'assurer que ces ressources précieuses sont allouées aux tâches qui auront le plus d'impact.
- Livrer de la valeur rapidement : Le principe de Pareto (la loi des 80/20) s'applique souvent au développement de produits : 80% de la valeur pour l'utilisateur provient de 20% des fonctionnalités. La priorisation aide à identifier et à construire ces 20% en premier.
- Donner de la visibilité et gérer les attentes : En classant clairement les éléments, vous communiquez aux parties prenantes (clients, management) ce qui sera fait, et dans quel ordre. Cela permet de gérer leurs attentes et d'éviter les déceptions.
- Fournir un cap à l'équipe de développement : Un backlog bien priorisé donne une direction claire à l'équipe. Ils savent sur quoi se concentrer et comprennent pourquoi leur travail est important.
Dans le cadre de Scrum, c'est le Product Owner qui est responsable de l'ordonnancement du Product Backlog pour en maximiser la valeur. Les techniques que nous allons voir sont ses principaux outils pour accomplir cette mission.
2. Technique 1 : La méthode MoSCoW
La méthode MoSCoW est une technique simple et efficace pour catégoriser les exigences. Elle est particulièrement utile pour se mettre d'accord sur le périmètre d'une version spécifique d'un produit, comme un Minimum Viable Product (MVP).
L'acronyme MoSCoW (les "o" ont été ajoutés pour le rendre prononçable) représente quatre catégories de priorité :
- Must have (Doit avoir)
- Should have (Devrait avoir)
- Could have (Pourrait avoir)
- Won't have (this time) (N'aura pas cette fois)
Pour bien comprendre chaque catégorie et la manière d'appliquer cette méthode, je vous invite à lire un article très clair sur le sujet.
Comprendre la méthode MoSCoW pour prioriser les exigences projet
L'article "Comprendre la méthode MoSCoW" du blog de la Wild Code School détaille parfaitement cette technique. Il explique l'origine, l'utilité et le fonctionnement de chaque catégorie avec des exemples concrets.
Lisez les sections "Qu’est-ce que la méthode MoSCoW ?", "Les 4 catégories en détail", "Comment appliquer MoSCoW à un projet ?" et "MoSCoW : exemple concret dans un projet agile". Concentrez-vous sur la définition de chaque catégorie et la différence entre elles.
Pour résumer ce que vous venez de lire :
- Must have : Ce sont les exigences non négociables. Sans elles, le produit est inutile ou illégal. Question clé : "Le produit fonctionne-t-il sans cela ?". Si la réponse est non, c'est un "Must have".
- Should have : Ces éléments sont importants et apportent une grande valeur, mais ne sont pas vitaux pour le fonctionnement de base. Il existe souvent une solution de contournement, même si elle est moins pratique.
- Could have : Ce sont les fonctionnalités "cerise sur le gâteau" (nice-to-have). Elles sont souhaitables mais leur absence aura peu d'impact. On les réalise si le temps et les ressources le permettent.
- Won't have (this time) : Cette catégorie est cruciale. Elle permet de statuer explicitement sur ce qui est hors du périmètre pour la version ou le Sprint en cours. Cela ne veut pas dire que l'idée est mauvaise, mais qu'elle ne sera pas traitée maintenant. C'est un outil très puissant pour gérer les attentes.
Appliquons la méthode
Testez votre compréhension !
Imaginez que vous êtes le Product Owner d'une nouvelle application mobile de e-commerce. Votre objectif est de lancer un MVP (Produit Minimum Viable) en trois mois. Voici une liste de User Stories. Classez-les en utilisant la méthode MoSCoW.
- En tant que client, je veux parcourir les produits par catégorie.
- En tant que client, je veux ajouter un produit à mon panier.
- En tant que client, je veux payer ma commande par carte de crédit.
- En tant que client, je veux consulter l'historique de mes anciennes commandes.
- En tant que client, je veux ajouter un article à une "liste de souhaits" pour le sauvegarder pour plus tard.
- En tant que client, je veux me connecter avec mon compte Google pour m'inscrire plus rapidement.
- En tant que client, je veux lire et écrire des avis sur les produits.
Quelle serait votre classification MoSCoW pour le MVP ?
Show answer
Il n'y a pas une seule bonne réponse, car cela dépend du contexte stratégique. Cependant, voici une classification très plausible pour un MVP :
-
Must have :
-
- Parcourir les produits par catégorie (essentiel pour trouver ce qu'on cherche).
-
- Ajouter un produit au panier (le cœur du processus d'achat).
-
- Payer par carte de crédit (sans paiement, pas de business).
-
-
Should have :
- 4. Consulter l'historique des commandes (très important pour le suivi et la fidélisation, mais le client recevra un email de confirmation en attendant).
-
Could have :
- 6. Se connecter avec Google (pratique, mais l'inscription par email/mot de passe suffit pour un MVP).
-
- Ajouter à une liste de souhaits (utile, mais pas indispensable pour le premier achat).
-
Won't have (for this MVP) :
- 7. Lire et écrire des avis (fonctionnalité complexe qui apporte plus de valeur quand il y a déjà un volume d'utilisateurs et de produits).
3. Technique 2 : La matrice Valeur vs. Effort
Une autre approche très visuelle et efficace est la matrice Valeur vs. Effort (ou Impact vs. Effort). Cette technique, très appréciée dans les environnements techniques, consiste à positionner chaque fonctionnalité sur un graphique à deux axes :
- L'axe vertical représente la Valeur : Quel est le bénéfice pour l'utilisateur ou pour l'entreprise ? (ex: augmentation des revenus, satisfaction client, réduction des coûts, etc.).
- L'axe horizontal représente l'Effort : Quelle est la complexité pour réaliser cette fonctionnalité ? (ex: temps de développement, risques techniques, dépendances, etc.).
Cette évaluation est un travail d'équipe : le Product Owner et les parties prenantes sont les mieux placés pour évaluer la Valeur, tandis que l'équipe de développement est la seule légitime pour évaluer l'Effort.
En plaçant les User Stories sur cette matrice, on obtient quatre quadrants qui suggèrent un ordre de priorité.
Pour approfondir, je vous propose de lire la description de cette technique.
Le guide pratique pour rédiger et prioriser un Product Backlog
L'article "Le guide pratique pour rédiger et prioriser un Product Backlog" décrit brièvement mais clairement cette matrice.
Lisez la section "2. La matrice Valeur vs. Effort". Elle explique le principe et les quatre quadrants qui en découlent.
Les quatre quadrants stratégiques sont donc :
- Gains rapides (Quick Wins) : Forte valeur, faible effort. Faites-les en premier ! Ce sont les plus rentables.
- Investissements (ou Projets majeurs) : Forte valeur, fort effort. Planifiez-les avec soin. Ce sont les grandes fonctionnalités qui constituent le cœur de votre produit, mais elles demandent du temps.
- Bouche-trous (Fillers) : Faible valeur, faible effort. Faites-les s'il reste du temps. Ils peuvent améliorer l'expérience sans coûter cher, mais ne doivent pas passer avant des tâches à plus forte valeur.
- À éviter (Time Sinks) : Faible valeur, fort effort. Remettez-les en question. Il faut généralement éviter de gaspiller des ressources sur ces tâches.
Appliquons la méthode
Testez votre compréhension !
Reprenons notre liste de User Stories pour l'application de e-commerce. Après discussion entre le PO (pour la valeur) et l'équipe de développement (pour l'effort), vous obtenez le tableau suivant. Placez chaque User Story dans le quadrant correspondant de la matrice.
| User Story | Valeur (estimée) | Effort (estimé) |
|---|---|---|
| 1. Parcourir les produits | Élevée | Moyen |
| 2. Ajouter au panier | Élevée | Faible |
| 3. Payer par carte de crédit | Élevée | Élevé |
| 4. Historique des commandes | Moyenne | Moyen |
| 5. Liste de souhaits | Moyenne | Faible |
| 6. Connexion avec Google | Faible | Faible |
| 7. Avis sur les produits | Moyenne | Élevé |
Show answer
Voici où chaque User Story se situerait :
-
Gains rapides (Quick Wins) - Forte Valeur / Faible Effort
- 2. Ajouter au panier
- (Potentiellement) 5. Liste de souhaits (Valeur Moyenne mais Effort Faible)
-
Investissements (Projets majeurs) - Forte Valeur / Effort Élevé
- 3. Payer par carte de crédit
-
- Parcourir les produits (Valeur Élevée, Effort Moyen, se situe souvent ici)
-
Bouche-trous (Fillers) - Faible Valeur / Faible Effort
- 6. Connexion avec Google
-
À éviter (ou à repenser) - Faible Valeur / Effort Élevé
- 7. Avis sur les produits (Valeur Moyenne, Effort Élevé, le ratio n'est pas idéal pour un début)
- L'historique des commandes (4) se situe au centre (Valeur Moyenne, Effort Moyen) et sa priorité dépendra de la stratégie.
Cette matrice suggère un ordre de développement : commencer par "Ajouter au panier" (2), planifier le travail pour "Payer par carte de crédit" (3) et "Parcourir les produits" (1), et intégrer "Liste de souhaits" (5) et "Connexion Google" (6) si le planning le permet.
Conclusion
La priorisation est l'une des activités les plus stratégiques de la gestion de produit agile. Elle garantit que l'équipe se concentre sur ce qui compte vraiment.
Ce qu'il faut retenir de cette leçon :
- La priorisation est un processus continu, pas une activité ponctuelle.
- La méthode MoSCoW est excellente pour définir le périmètre d'une release en distinguant l'essentiel (Must) du superflu (Could/Won't).
- La matrice Valeur vs. Effort est un outil visuel puissant pour optimiser l'ordre de développement et identifier les "gains rapides".
- Ces techniques ne sont pas des formules magiques, mais des outils de facilitation pour structurer la conversation entre les parties prenantes et l'équipe de développement.
Vous avez maintenant toutes les cartes en main : un Product Backlog contenant des User Stories bien écrites, et des techniques pour les ordonner de manière stratégique.
Dans la prochaine leçon, nous passerons à l'action. Maintenant que notre backlog est priorisé, nous apprendrons à animer une réunion de planification de Sprint (Sprint Planning) pour sélectionner le travail à réaliser et définir un objectif clair pour les semaines à venir. Ce sera la première étape du Module 7, "Pilotage d'un Projet avec Scrum". À bientôt