Cycle de vie des éléments du carnet de produit

Récemment, quelqu’un a demandé à notre communauté quel est le cycle de vie d’un scénario utilisateur (user story) et en quoi il diffère des épiques, des fonctionnalités et des thèmes. Je souhaite vous partager mes réflexions à ce sujet.

La première question qui m’est venue à l’esprit a été : « Est-ce que les éléments du carnet de produit (Product Backlog Items ou PBIs) sont tous égaux? »

Ces éléments (PBIs) représentent le travail à accomplir pour un produit et documentent la valeur de ce travail. Bien que la façon de décrire le travail puisse varier, ils suivent tous le même cycle :

Le « comment » de chacune de ces étapes est défini par chaque équipe et sera probablement différent en fonction du type de PBI. Les épiques, fonctionnalités et thèmes sont tous de potentiels PBIs qui suivent les mêmes étapes.

Saisie

C’est à cette étape que les idées sont générées et documentées. Elles peuvent provenir d’une multitude de sources, incluant des ateliers d’idéation, la rétroaction directe des clients, le service de soutien, les parties prenantes, la compétition, etc.

Une grande proportion des idées saisies ne se rendent même pas à l’étape du raffinement. Elles sont habituellement évaluées négativement par rapport aux résultats attendus et simplement supprimées. Les idées qui sont conservées sont transformées en PBIs.

Mon premier carnet de produit contenait 2000 éléments. Je ne pouvais supporter la perspective de supprimer des idées. Je pensais que le carnet de produit était l’endroit où documenter toutes les idées. Pas besoin de vous dire que garder un tel carnet de produit ordonné et hautement visible était une tâche impossible.

Si quelque chose a plus de six mois, reconsidérez sa place. Si c’est important, cela reviendra.

Regrouper les PBIs en thèmes, épiques et fonctionnalités est une excellente idée pour garder votre carnet ordonné et compréhensible. Comme pour tout autre élément, la valeur associée au travail est documentée. Le truc c’est que parfois tous les éléments du carnet liés à un tel groupe sont mis à la poubelle (oui, la poubelle!) La raison en est fort simple : lorsque vous commencez à raffiner un thème, une épique ou une fonctionnalité, de nombreuses choses peuvent avoir changé et vous en aurez peut-être appris plus à ce sujet. Au moment venu, vous le raffinerez et générerez des idées plus pertinentes.

Raffinement

L’objectif du raffinement est de mieux comprendre le travail à venir et de s’assurer que chaque PBI est aussi petit que possible. Les avantages d’avoir de petits éléments incluent un cycle d’apprentissage plus rapide, un effort plus facile à estimer et une livraison plus rapide.

Les activités de raffinement incluent diviser les gros éléments, préciser les plus petits en fournissant des détails et souvent, évaluer le travail nécessaire. La partie qui nous intéresse ici est « diviser les plus gros éléments. »

Durant les activités de raffinement, l’équipe de développement de produit, souvent aidée par les parties prenantes, cherche à diviser les gros éléments et explorer les épiques, les thèmes et les fonctionnalités. Le résultat de l’activité devrait être un nouvel ensemble de PBIs considérés comme nécessaires pour atteindre la valeur des gros éléments. Ces derniers sont ensuite éliminés. La raison est bien simple : si nous ne les éliminons pas, nous nous retrouvons avec des dépendances et des doublons dans le carnet de produit, créant ainsi de la confusion.

Comme Product Owner, j’avais l’habitude d’ordonnancer mes épiques et mes fonctionnalités afin de surveiller l’avancement du travail. Après quelques mois, je me suis retrouvé avec six épiques en cours et je devais surveiller leurs dépendances respectives. Cela me donnait simplement plus de travail et me faisait comprendre que j’étais plutôt mauvais pour le diviser.

C’est à ce moment que j’ai commencé à me concentrer sur l’impact que je cherchais à générer et à trouver des métriques pertinentes. Laissez-moi illustrer ceci par le biais d’un petit scénario :

Développement et livraison

J’ai vu de nombreuses équipes arrêter de surveiller leur PBI une fois que l’élément était considéré comme « terminé », c’est-à-dire « lancé » ou « prêt pour le lancement. » Personnellement, j’aime les garder jusqu’à l’étape de la validation comme rappel de nos hypothèses de valeur.

Validation

J’ai vu des gens travailler sans relâche jour et nuit sur des produits, sans valider leur travail, sans jamais lancer quoi que ce soit jusqu’à ce qu’ils aient l’impression que c’était terminé. J’ai vu des petites entreprises mourir et des millions de dollars d’investissement brûler, simplement parce qu’elles craignaient un échec en lançant quelque chose trop tôt.

Pour cette étape, chaque équipe trouve la meilleure façon de valider ses hypothèses. Certaines équipes font de la validation une partie intégrante de leur processus de développement et de livraison. Ces équipes font, ou sont sur le point de faire, de la livraison continue. Les PBIs sont alors supprimés une fois qu’ils ont été validés.

Les autres équipes peuvent conserver leurs PBIs comme hypothèses à valider ou les regrouper en éléments de valeur plus grands. Cela fonctionne bien, tant et aussi longtemps que nous ne surveillons pas que l’impact d’affaires de la livraison. Le plus important est que nous validions la valeur pour nos utilisateurs.

Dans mon scénario de la fonctionnalité courriel ci-dessus, il pourrait être tentant de valider : « Est-ce que nos utilisateurs restent sur la plateforme après le lancement de la fonctionnalité courriel? » Cela tient pour acquis que nous savons d’avance ce que fera la fonctionnalité et ce dont elle aura l’air… ce qui n’est vraisemblablement jamais le cas. Nous devons valider que nous livrons de la valeur à notre utilisateur présumé pour chacun des PBIs « Écrire », « Envoyer » et « Lire. »

En gardant cela à l’esprit, concluons que conserver les PBIs jusqu’à ce qu’ils soient validés pourrait être une bonne façon de compléter leur cycle de vie…