Quel niveau de détail devrait avoir le Backlog Produit ?
Auteur : Roman Pichler (@romanpichler)
Source : How Detailed should the Product Backlog be?
Date : 14/07/2015
Traducteur : Fabrice Aimetti
Date : 12/08/2015
Traduction :
Le Backlog Produit est un super outil. Mais l'utiliser efficacement peut se révéler difficile. L'un des défis à relever est de disposer du bon niveau de détail. Un backlog trop détaillé est trop lourd et difficile à manier. Mais un Backlog Produit qui a une trop grosse granularité n'est pas non plus très utile : il ne guide pas suffisamment l'équipe de développement. Ce billet a pour objectif de vous aider à trouver le bon équilibre entre trop et pas assez de détail. Il vous montre comment déterminer le bon niveau de détail pour votre Backlog Produit.
Théorie et Pratique
En théorie, votre Backlog Produit doit être priorisé avec les éléments de plus haute priorité en haut et les éléments de plus basse priorité en bas. Les éléments du haut doivent être détaillés et de fine granularité. Au fur et à mesure que la priorité décroît, la granularité des éléments devient de plus en plus épaisse. Vous pouvez représenter les éléments du haut sous la forme de petites user stories prêtes à être développées dans le sprint suivant. Mais plus profond dans le backlog, vous utiliserez des epics, qui sont de grosses stories peu détaillées. Par conséquent, le niveau de détail des éléments dépend de leurs priorités, comme le montre l'image suivante :
Si votre Backlog Produit ne ressemble pas à ça, cela veut-il dire qu'il est mauvais ?
Le Cycle de vie du Produit
Je pense qu'un Backlog Produit tel qu'illustré ci-dessus est optimal pour un produit jeune. Typiquement, dans cette phase du cycle de vie, vous devez expérimenter de nouvelles idées et faire régulièrement des changements dans votre produit, par exemple, découvrir les fonctionnalités et l'interface utilisateur qui soient les plus adaptées, les améliorer ou les optimiser. Par conséquent, vous souhaitez être capable de changer votre backlog facilement, le maintenir concis, et avoir un petit nombre d'éléments détaillés. Sinon, les mises à jour génèreront trop d'efforts et prendront trop de temps.
Mais au fur et à mesure que votre produit se stabilise et mûrit, vous apprenez à mieux comprendre le marché, les besoins des clients et comment les satisfaire. Cela accroît votre capacité à anticiper la façon dont votre produit va probablement évoluer. Par conséquent, vous pouvez davantage détailler votre backlog.
Le niveau de détail de votre backlog est donc lié l'étape du cycle de vie dans laquelle se trouve votre produit. Un jeune produit devrait avoir un backlog concis avec peu de détails ; des produits stables, âgés tireront avantage à avoir un backlog plus détaillé, comme le montre l'image suivante :
Le Backlog Produit à gauche de la courbe du cycle de vie contient des éléments peu détaillés ; la plupart de son contenu a une grosse granularité. Mais le backlog de droite est l'opposé : il contient beaucoup plus d'éléments détaillés et de granularité plus fine. Par conséquent, il est plus grand et moins concis. Mais veillez bien à ce que votre backlog ne croît pas de façon incontrôlée voire même ne se transforme en une liste de souhaits. Complétez-le avec une feuille de route (NdT : roadmap) du produit pour représenter les perspectives à plus long-terme sur la façpn dont votre produit va probablement croître.
Même si le cycle de vie du produit est intéressant pour calibrer le bon niveau de détail de votre backlog, cela ne suffit pas. Vous devez aussi considérer où se positionne votre produit dans le cycle des versions.
Le Cycle des Versions
Lorsque vous commencez à travailler sur une nouvelle version ou une version majeure du produit, pensez à iOS 8.4 ou WIndows 10, vous faites face à davantage d'incertitudes et de risques qu'à la fin du projet. Si vous traitez le risque trop tôt, alors votre Backlog Produit est particulièrement volatile durant les premiers sprints. Au fur et à mesure que vous testerez vos hypothèses et traiterez les risques, vous allez probablement découvrir que certaines de vos hypothèses étaient fausses et générer de nouvelles idées. Les nouvelles idées et pistes nécessitent de changer le Backlog Produit, et certains changements peuvent être assez importants, surtout si votre produit est jeune. Vous allez donc tirer avantage à disposer d'un backlog concis avec une grosse granularité au début de la nouvelle version.
Mais une fois que vous avez traité les risques majeurs et les hypothèses critiques, votre objectif consiste alors à terminer et optimiser les fonctionnalités, comme je l'ai justement expliqué dans mon billet : Adoptez le bon focus : Apprendre et Exécuter en Scrum. A cette étape, votre Backlog Produit doit commencer à se stabiliser et connaître moins et de petits changements. Par conséquent, vous pouvez ajouter davantage de détails.
De manière empirique, utilisez peu de détails au début du projet ou de la version et davantage de détails une fois que vous avez traité les risques majeurs et que votre produit a commencé à se stabiliser.
Conclusion
Utilisez le cycle de vie du produit et le cycle des versions pour déterminer le niveau de détail correct du produit. Cela fonctionne pour les backlogs traditionnels aussi bien que pour les storymaps de Jeff Patton que pour mon Product Canvas. Pour faire simple, plus vous ferez face à des incertitudes et des changements, plus vos backlogs devraient être concis et de grosse granularité.
Au fur et à mesure que votre produit se développe et mûrit, ajustez votre Backlog Produit et la manière dont vous le gérez. Il n'y a pas un unique niveau de détail.
