Qu’est-ce que le Product Backlog ?
Le Product Backlog (Backlog Produit) est le premier des trois artefacts clés du framework de gestion de projet Agile Scrum. Les autres artefacts sont le Sprint Backlog et l’Incrément Produit. Il centralise toutes les fonctionnalités, besoins techniques et fixes à implémenter pour atteindre votre vision produit et vos objectifs.
Sous la responsabilité du Product Owner, le Product Backlog est constamment enrichi à la lumière des nouvelles données provenant du marché, des utilisateurs ou des autres parties prenantes. Sous leur forme brute, les éléments bruts du Product Backlog sont généralement des idées, des fonctionnalités (Features) ou des Epics. Ces éléments doivent être régulièrement affinés de façon à les transformer en User Stories prêtes à être développées et ajoutées au Sprint Backlog.
Comment déterminer les éléments à ajouter au Product Backlog ?
Déterminer les éléments à ajouter au Product Backlog recquiert de s’appuyer sur une vision claire des enjeux business et produit. En ce qui concerne la traduction des enjeux business en éléments de backlog, vous pouvez utiliser l’Impact Mapping. Pour ce qui est de la cohérence produit, le User Story Mapping vous permettre de cartographier et de répondre de façon optimale aux besoins de vos utilisateurs. La Méthode MoSCoW, elle, vous aidera à hiérarchiser simplement les différents niveaux de richesse fonctionnelle.
L’Impact Mapping
L’Impact Mapping est une méthode qui aide à établir et à cartographier les relations de causalité entre un objectif, les acteurs impliqués, les impacts attendus sur ces différents acteurs, et les livrables ou les initiatives qui ont un impact sur ces acteurs ou leur permet d’avoir un impact.
Les livrables qui résultent de l’atelier d’Impact Mapping sont autant d’éléments que vous pouvez ajouter à votre Product Backlog et qui contribueront très directement à l’atteinte de vos objectifs.
En savoir plus sur l’Impact Mapping →
Le User Story Mapping
Le User Story Mapping est un exercice de projection de l’utilisateur dans les différents trajets d’un produit afin de déterminer le périmètre fonctionnel cohérent et optimal à fournir audit l’utilisateur pour lui permettre de parvenir à ses fins et de tester le plus rapidement possible son produit ou une nouvelle fonctionnalité.
On regroupe généralement cet ensemble cohérent de User Stories sous le terme de MVP pour Minimum Viable Product et de MMF pour Minimum Marketable Feature.
En savoir plus sur le User Story Mapping →
La Méthode MoSCoW
La Méthode MoSCoW apporte un cadre de réflexion utile pour déterminer les différentes versions cible d’un même produit en fonction de l’importance des besoins utilisateurs visés et des contraintes techniques endogènes (sécurité, fiabilité, etc.) ou exogènes (réglementation, dépendances avec le reste de l’organisation, etc.) de l’équipe.
En savoir plus sur la Méthode MoSCoW →
Comment hiérarchiser les éléments de son Product Backlog ?
Une fois les fonctionnalités listées et documentées dans votre Product Backlog, il reste à sélectionner celles à implémenter prochainement. L’exercice de priorisation peut s’avérer délicat, qui plus est quand il faut gérer des demandes aux origines diverses et variées : utilisateurs, concurrents, commerciaux, fondateurs, etc.
Fort heureusement, il existe plusieurs techniques de priorisation qui vous aideront à objectiver la sélection des prochaines fonctionnalités à développer. Dans cet article, nous vous présentons deux techniques, mais sachez qu’il en existe beaucoup d’autres.
Matrice de Priorisation
La Matrice de Priorisation est une façon simple et efficace de trier les fonctionnalités d’un Product Backlog. L’axe des abscisses représente la faisabilité de la fonctionnalité, i.e., l’inverse la complexité, et l’axe des ordonnées représente la valeur business ou autre.
Pour de déterminer la faisabilité et la valeur, l’atelier doit réunir toutes les parties prenantes pertinentes : business owners, développeurs, etc.
En savoir plus sur la Matrice de Priorisation →
Framework ICE (Impact x Confidence x Ease)
Le Framework ICE permet de calculer un score qui agrège trois aspects complémentaires :
- L’impact (Impact) estimé que la fonctionnalité aura sur le produit, et plus précisément, sur l’indicateur que vous souhaitez améliorer ;
- La confiance (Confidence) que vous avez en le fait que cette fonctionnalité aura bien un impact sur l’indicateur que vous souhaitez améliorer ;
- La facilité d’implémentation (Ease of implementation) de la fonctionnalité, i.e., l’inverse de la quantité d’effort nécessaire à son implémentation.
Chacun des trois axes doit être évalué sur une échelle allant de 1 à 10. Le score ICE est le produit de ces trois évaluations. Plus le score est élevé, plus la fonctionnalité est prioritaire.
En savoir plus sur le Framework ICE →
Comment affiner son Product Backlog ?
Une fois les fonctionnalités prioritaires identifiées (ou Features), le rôle du Product Owner est de rédiger les User Stories, i.e., d’une part, de les documenter – description, critères d’acceptation, règles de gestion fonctionnelles et non-fonctionnelles, etc. -, puis, avec l’aide de l’équipe de développement, de les estimer. C’est l’objet des sessions de Backlog Refinement (ou Backlog Grooming).
L’objectif est qu’une User Story puisse être implémentée au cours d’un sprint. Bien évidemment, une fonctionnalité peut se décomposer en plusieurs User Stories. L’estimation d’une User Story s’exprime généralement en Story Points et s’effectue par l’intermédiaire d’un Planning Poker.
Le Planning Poker
Le Planning Poker (ou Scrum Poker) est une méthode d’estimation de la charge associée à l’implémentation d’une User Story. Cette méthode est généralement utilisée lors des sessions de Backlog Refinement (ou de Backlog Grooming), en préparation de la session de Sprint Planning, afin de dimensionner les éléments du backlog et d’éventuellement affiner les User Stories, c’est-à-dire, les redécouper en deux ou plusieurs User Stories plus petites.
En savoir plus sur le processus d’estimation et le Planning Poker →
