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 :

PBI cycle FR

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 :

Je suis le Product Owner d’un logiciel d’entreprise. Nous croyons que nos utilisateurs se déconnectent de notre plateforme parce que nous n’avons pas de fonctionnalités de communication. Pour transposer cela dans mon carnet de produit, j’écris une fonctionnalité intitulée « Courriel » avec l’affirmation de valeur suivante : « Nous voulons que nos utilisateurs communiquent plus par le biais de la plateforme afin qu’ils ne la quittent pas. »

Après quelques mois, quand la fonctionnalité entre dans le court à moyen terme, nous la raffinons. Dans ce scénario, « nous » c’est moi, l’équipe de développement ainsi que quelques utilisateurs.

Nous avons initialement réfléchi aux actions possibles qu’un utilisateur peut vouloir effectuer avec un courriel.

Écrire, Modifier, Supprimer, Lire, Envoyer à une personne, Envoyer à plusieurs personnes, CC, CCI, Archiver, Filtrer, Sauvegarder comme brouillon, …

Nous avons d’abord considéré demander seulement les fonctionnalités d’écriture, d’envoi et de lecture pour commencer à livrer de la valeur, lorsqu’un développeur a suggéré qu’il serait vraiment facile d’intégrer simplement une plateforme de clavardage, qui consiste somme toute en « écrire, envoyer et lire. » À ce moment, une décision pouvait être prise :

  1. Nous conservons la fonctionnalité dans le carnet et documentons les actions de l’utilisateur comme critères d’acceptation de cette fonctionnalité. Nous écrivons ensuite un PBI pour implémenter une fonctionnalité de clavardage.
  2. Nous ignorons la suggestion de clavardage tirée de la rétroaction des utilisateurs et écrivons de nouveaux PBIs pour les actions utilisateurs; avec les PBIs Écrire, Envoyer et Lire en premier. Certaines ou toutes les idées secondaires peuvent être supprimées au fur et à mesure que nous apprenons à propos du marché.
  3. Nous conservons la suggestion de clavardage en écrivant un PBI pour celle-ci et nous créons quand même les PBIs de courriel.

Dans ce scénario, si nous divisons le PBI « Courriel », il sera remplacé dans le carnet de produit par des PBIs qui représentent les actions de l’utilisateur. Nul besoin de surveiller son implémentation puisque nous surveillons le lancement et/ou les effets sur les métriques.

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…

Luc St-Laurent

Luc est un professionnel certifié Scrum (CSP) et un coach Agile. Il a commencé son trajet dans les technologies de l’information il y a plus de 20 ans, et ce, bien avant d’adopter les valeurs Agiles (2007). Il se dévoue à aider les équipes et les gestionnaires à mieux collaborer afin de livrer un meilleur produit entre les mains de l’utilisateur. Luc croit au développement personnel au sein de l’équipe et au développement de l’équipe au sein de l’organisation. Il aspire à croire au développement de l’organisation au sein de notre société.

Billet précédent

C'est extra!

Billet suivant

(RE) Trouver son calme au cœur de la tempête

Pas de commentaire

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.