Qu'est-ce qu’un Product Backlog et qui en est responsable ?
Un product backlog est une liste ordonnée de tout ce qui est nécessaire pour développer et lancer un produit. Il contient des fonctionnalités, des améliorations, des corrections, et d'autres éléments nécessaires pour réaliser le produit final. Le Product Owner, est généralement responsable de la gestion du backlog. C'est lui qui a la vision du produit et qui prend les décisions finales concernant ce qui sera construit, dans quel ordre et pourquoi.
Le Product Owner est aidé par l'équipe de développement et d'autres parties prenantes pour identifier et affiner les éléments du backlog. Cette collaboration est essentielle pour s'assurer que le backlog reflète les besoins réels des utilisateurs et les objectifs stratégiques de l'organisation.
Pour cela, le Product Owner va traduire les besoins des utilisateurs en User Stories qui seront ensuite priorisés dans le backlog. Lors de ce processus, le PO s’appuie sur la vision stratégique du Product Manager.
Comment et sur quels critères sont ordonnées les éléments du backlog produit ?
Les User Stories (US), sont ordonnés principalement selon leur priorité, qui dépend de leur impact sur les utilisateurs et de leur contribution aux objectifs business. Le Product Owner, avec l'input de son équipe et d'autres stakeholders, évalue chaque élément en fonction de sa valeur, de son urgence, et de sa complexité. Cette évaluation aide à déterminer l'ordre de développement des fonctionnalités.
Pour prioriser efficacement les US dans son backlog, plusieurs critères doivent être pris en compte :
Maintenant que nous savons sur quels critères prioriser nos fonctionnalités dans le product backlog, un peu de pratique grâce à plusieurs méthodes et ateliers de priorisation.
5 méthodes et ateliers de priorisation du backlog
Il existe de nombreuses méthodes de priorisation à disposition pour prendre en compte les différents critères précédemment cités, voyons ensemble 5 exemples les plus pertinents selon nous :
Méthode de priorisation MoSCoW
La méthode MoSCoW vise à prioriser, de façon simple, les tâches en fonction de leur importance pour le produit et pour les utilisateurs.- M – Must have : les éléments vitaux pour votre produit.
- S – Should have : les éléments importants, mais pas vitaux pour votre produit.
- C – Could have : les éléments qui pourront être développés s’ils n’ont pas d’impact sur les tâches vitales.
- W – Won’t have : les éléments avec moins ou pas de valeur immédiate et qui pourront être réévalués dans une version ultérieure du produit.
Comment prioriser avec Weighted Shortest Job First (WSJF) ?
Le “Weighted Shortest Job First” a pour objectif de faire ressortir les features les plus importantes et les plus rapides à développer en top de votre backlog. Le calcul de l’indicateur WSJF tiendra compte des valeurs suivantes :
- Business value : la valeur métier de la fonctionnalité estimée avec les parties prenantes.
- Niveau d’urgence : la fonctionnalité doit-elle être livrée rapidement ? Quelle criticité pour cette fonctionnalité ?
- Réduction des risques / Facilitation des développements : sécurisation de l’application, système de déploiement qui n’implique aucune interruption de service par exemple.
- Taille de la fonctionnalité à développer : points de complexité estimés par l’équipe de développement.
RICE : méthode de priorisation
Chaque fonctionnalité est évaluée en fonction de quatre facteurs : Reach, Impact, Confidence et Effort. Cette méthode est particulièrement utile pour estimer l'impact potentiel des fonctionnalités sur les utilisateurs.
- R - Reach ou la Portée : la fonctionnalité impactera potentiellement X clients
- I - Impact : la fonctionnalité a une valeur plus ou moins élevée pour nos clients
- C - Confidence ou la Confiance : le degré de certitude dans la capacité à délivrer la fonctionnalité sans risque
- E - Effort : les ressources nécessaires pour développer la fonctionnalité (estimation en story points ou en taille de t-shirt S,M,L, XL par exemple)
KANO : priorisation des features
Cette méthode permet de prioriser les features en fonction de leur attractivité et de leur performance : Basiques, Attractives, Indifférentes, Unidimensionnelles et Inversées.
Le modèle Kano consiste à questionner ses utilisateurs sur leur ressenti à propos de la présence ou non de la fonctionnalité dans le produit :
- Like it : j’aime cette fonctionnalité.
- Expect it : j’attends ou espère cette fonctionnalité.
- Don’t Care : je suis neutre.
- Live with : je fais avec, je m’en contente.
- Dislike : je n’aime pas la fonctionnalité, elle me déplaît fortement.
Atelier de priorisation : Buy a feature
Buy a feature est un atelier de simulation à organiser et animer. Lors de cet atelier, les parties prenantes utilisent un budget fictif pour "acheter" les fonctionnalités qu'elles considèrent les plus précieuses. Cela aide à visualiser les priorités des utilisateurs et des parties prenantes.
Généralement, voici les étapes de l’atelier :
- Convier tous les acteurs du projet.
- Leur distribuer de l’argent (la même somme pour tous).
- Rendre de manière visible (post-its) les différentes fonctionnalités sur lesquelles ils vont devoir se pencher avec un prix pour chacune. Expliquez-les.
- Les participants achètent les fonctionnalités.
- Une fois terminé, on fait les comptes pour voir les fonctionnalités retenues.
- On débat sur la sélection qui est ressortie et vous avez votre priorisation.
Pour aller plus loin sur les méthodes de priorisation, découvrez nos articles dédiés sur le sujet :
La Guerre du Backlog n'aura pas lieu (PART 1)
La Guerre du Backlog n'aura pas lieu (PART 2)
Conclusion : prioriser son backlog pour délivrer de la valeur à ses utilisateurs et répondre aux objectifs business
Prioriser efficacement un backlog produit est crucial pour s'assurer que l'équipe se concentre sur les tâches qui apportent le plus de valeur au produit et aux utilisateurs finaux. En utilisant des méthodes éprouvées et en impliquant toutes les parties prenantes dans le processus de priorisation, vous pouvez non seulement accélérer le développement mais aussi améliorer la qualité et la pertinence de votre produit.
En adoptant ces pratiques, vous positionnerez votre produit pour un succès durable sur le marché, répondant ainsi non seulement aux besoins actuels de vos utilisateurs mais aussi en anticipant leurs besoins futurs.
Marion Peaudecerf Roxanne Marchand Maeva Charron
@ElevenLabs @ElevenLabs @ElevenLabs
Besoin d’être accompagné par un Product Owner pour organiser votre Product Backlog et suivre l’avancement avec vos développeurs ?
Organisons un échange !
Demander un rendez-vous