Le flux de valeur

De la Vision au Product Backlog

Une équipe manque rarement d'idées. Elle en a plutôt trop, portées par des personnes différentes, et elle ne peut pas les réaliser toutes à la fois. Les patterns de Scrum décrivent le chemin qui mène d'une intention commune, la Vision, à une liste unique et ordonnée, le Product Backlog. Cet article suit ce chemin et explique sur quels critères on décide de l'ordre.

Trop d'idées pour une seule équipe

Il manque à cette équipe une direction partagée et une manière de décider ce qui passe en premier. Dans A Scrum Book (2019), Jeff Sutherland, James Coplien et leurs coauteurs décrivent la réponse de Scrum par des patterns qui s'enchaînent. Un pattern est une solution éprouvée à un problème récurrent, présentée avec son contexte et les forces qui s'y opposent.

La Vision, une direction que l'équipe s'approprie

Le pattern Vision (les auteurs l'appellent aussi Product Vision, la vision du produit) part d'une tension. Des personnes aux parcours variés apportent des idées qu'une seule n'aurait pas eues, mais sans but commun elles tirent dans des directions différentes. Un but trop vague laisse l'équipe se disperser sur des pistes de faible intérêt. Un but trop étroit lui retire sa créativité et transforme ses membres en exécutants. L'avenir est en outre trop incertain pour qu'on s'engage longtemps à l'avance sur un plan détaillé.

La solution proposée est la suivante. La personne qui porte le projet avec le plus de conviction prend le rôle de Product Owner, c'est-à-dire de responsable de la valeur du produit. Autour d'elle, les parties prenantes (toutes les personnes concernées par le produit) et les futurs coéquipiers formulent puis affinent ensemble une Vision : la description d'un avenir souhaité et de la façon dont le produit y contribue. Les auteurs insistent sur ce travail en commun, car une équipe ne fait sien un but que si elle a participé à sa formulation.

Le pattern distingue deux niveaux. La Vision donne une direction large, et la Product Vision la précise. En s'appuyant sur Roman Pichler (Agile Product Management with Scrum, 2010), les auteurs indiquent ce que celle-ci contient d'ordinaire : les principales caractéristiques du produit, ses utilisateurs, les besoins auxquels il répond et le bénéfice qu'en tire l'organisation. Ils citent en exemple la formule de Bill Gates et Paul Allen, un ordinateur sur chaque bureau et dans chaque foyer. Une Vision se corrige à mesure que l'équipe apprend.

À la médiathèque, après deux réunions avec l'adjointe, les agents et quelques usagers, la directrice retient cette phrase : « Chaque habitant du quartier a une raison de venir à la médiathèque au moins une fois par mois. » La phrase ne dit pas quoi faire, mais elle permet déjà de comparer les idées entre elles.

Le Value Stream : le chemin de l'idée à l'usager

Une bonne idée et des personnes compétentes ne suffisent pas. Le chemin par lequel l'idée devient un service rendu compte autant que l'idée. C'est le problème que traite le pattern Value Stream (flux de valeur, ou chaîne de valeur). Les auteurs y définissent la valeur comme ce qui a du prix pour les personnes que l'on veut servir.

La solution consiste, pour le Product Owner, à bâtir un ensemble cohérent d'artefacts, d'événements et de personnes, au centre duquel un processus livre régulièrement aux parties prenantes des incréments, c'est-à-dire des versions utilisables et enrichies du produit. Le pattern pose une règle d'organisation : une seule Scrum Team (le Product Owner, le Scrum Master et les développeurs) assure tout le développement d'un flux de valeur, sans passage de relais important vers d'autres équipes. Chaque passage de relais retarde le retour d'information, et ce retard se paie en travail à refaire. Le flux circule aussi dans l'autre sens, puisque les remarques des usagers et les défauts constatés remontent vers l'équipe.

La notion vient du Lean : les auteurs renvoient au système de production Toyota et à la cartographie de la chaîne de valeur, que présente le corpus Lean. À la médiathèque, le flux part d'une idée de service et se termine quand un habitant en profite. Si le catalogage dépend d'un service de la mairie qui répond en trois semaines, ce relais ralentira tout le reste.

Le Product Backlog, une seule liste ordonnée

Le pattern Product Backlog (parfois traduit par « carnet de produit ») répond au problème de la scène d'ouverture. Une équipe ne peut pas tout faire en même temps et doit garder sa concentration. Les parties prenantes ont besoin de voir où va le produit. L'ordre de livraison doit tenir compte des dépendances entre les réalisations et du calendrier. Si chacun tient sa propre liste, personne ne peut voir cet ordre.

La solution est de tenir, pour chaque produit, une liste unique dont les éléments sont rangés dans l'ordre où l'on prévoit de les livrer. Le Product Owner a le dernier mot sur son contenu et sur son ordre, mais il la construit avec les développeurs, ceux qui réalisent le produit. La liste est visible de tous, et les développeurs ne reçoivent de travail d'aucune autre source.

Les auteurs ajoutent deux précisions. Le Product Backlog n'est pas un cahier des charges : il enregistre les décisions de planification de l'équipe, et les détails se discutent de vive voix. Par ailleurs, les prévisions qu'on en tire n'ont de sens que pour deux à cinq Sprints (le Sprint est la période de travail de durée fixe, d'un mois au plus, qui rythme Scrum).

Le Product Backlog Item

Chaque ligne de la liste est un Product Backlog Item (élément du Product Backlog, abrégé PBI). Le pattern le définit comme la description d'une chose que les développeurs peuvent réaliser et livrer, et qui apporte de la valeur à une partie prenante une fois terminée. Un bon PBI porte un nom facile à retenir, une estimation fournie par les développeurs et une note sur la valeur attendue. Il dit quoi, quand et pour qui, et laisse le comment aux développeurs.

Les auteurs tiennent à une distinction : le PBI décrit un livrable, alors qu'une user story (un court récit du type « en tant que lecteur, je veux… afin de… ») décrit le besoin et la motivation d'une personne. Un même livrable peut répondre à plusieurs récits. Ils déconseillent aussi d'y inscrire les tâches internes de l'équipe, qui ont leur place dans le plan de travail du Sprint. À la médiathèque, « acheter douze caisses de transport » est une tâche. « Les résidents des Tilleuls reçoivent chaque mois cinq livres choisis avec eux » est un PBI.

Quatre patterns pour décider de l'ordre

Value and ROI

Scrum a longtemps désigné la valeur par le sigle ROI (return on investment, retour sur investissement). La note Value and ROI (valeur et retour sur investissement) en élargit le sens. Les auteurs y relèvent que le Guide Scrum n'emploie pas le terme ROI et parle seulement de valeur. Pour un service public, celle-ci peut se mesurer à la satisfaction des citoyens. En reprenant l'ingénieur Arthur D. Hall (A Methodology for Systems Engineering, 1962), ils distinguent une valeur économique, une valeur psychologique (la satisfaction des personnes) et une valeur qu'ils appellent casuistique, celle de faire ce qui est juste.

ROI-Ordered Backlog

Le pattern ROI-Ordered Backlog (backlog ordonné selon le retour sur investissement) cherche le critère d'ordre. Suivre les souhaits du client le plus important écarte les autres et néglige les coûts. Ne suivre que les dépendances techniques fait manquer des occasions. Trier les éléments selon la valeur notée sur chacun semble aller de soi, mais la valeur d'un élément dépend de ce qui a été livré avant lui et du moment où il arrive.

La solution est que le Product Owner ordonne la liste de façon à obtenir la plus grande valeur à long terme, en comptant les recettes et les coûts, après avoir écouté les parties prenantes. Les auteurs précisent que ce choix se réduit rarement à une formule et qu'il demande du jugement. Ils en tirent une remarque de vocabulaire : la « priorité » est un attribut que l'on colle sur un élément isolé, alors que la valeur naît de la position de chaque élément dans l'ensemble. Le Guide Scrum a fait le même choix dès 2011, en remplaçant « priorisé » par « ordonné ». À la médiathèque, l'espace devoirs vaut davantage s'il ouvre en septembre qu'en mai, et le portage à domicile suppose que le catalogue en ligne soit refait.

High Value First

Le pattern High Value First (la plus forte valeur d'abord), adapté de Joe Bergin (Agile Software: Patterns of Practice, 2013), propose une autre voie pour un contexte précis : un client unique confie un développement à un prestataire, et le rôle de Product Owner se trouve du côté du client. Une valeur raisonnable obtenue tôt y compte plus qu'une valeur maximale obtenue tard. La solution consiste à réaliser d'abord les éléments de plus forte valeur, à reprendre à chaque Sprint le meilleur élément restant et à arrêter le projet lorsque le coût d'un Sprint dépasse la valeur qu'il apporte.

ROI-Ordered Backlog et High Value First sont présentés comme deux options : le premier accepte de perdre un peu à court terme pour gagner davantage sur la durée, le second fait l'inverse et ouvre la voie aux formes de contrat décrites dans l'article sur le plan de livraison.

Greatest Value

Le pattern Greatest Value (la plus grande valeur) traite un travers fréquent : une équipe qui calcule la valeur comme la somme de ses parties améliore chaque partie aux dépens du tout. La solution demandée est de rechercher la plus grande valeur d'ensemble, à l'échelle la plus large sur laquelle l'organisation a prise, et de conduire le travail local avec cette vue. Les auteurs citent deux produits d'une entreprise européenne de logiciels de télécommunications qui partageaient une base de données : une modification coûteuse pour l'un servait l'ensemble, et les deux Product Owners ont décidé ensemble de la faire.

Ce que dit le Guide Scrum 2020

Le livre date de 2019 et s'appuie sur l'édition 2017 du Guide Scrum. L'édition 2020 présente quelques écarts.

• Le Guide ne parle pas de Vision. Il a introduit en 2020 le Product Goal (objectif de produit) : un état futur du produit qui sert de cible à la Scrum Team, inscrit dans le Product Backlog, et que l'équipe doit atteindre ou abandonner avant d'en viser un autre.
• Le Guide décrit le Product Backlog comme une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit, et comme la source unique du travail de la Scrum Team. Il concorde ici avec le pattern.
• Le Guide n'emploie ni ROI ni Value Stream, et il ne prescrit aucun format pour les éléments du Product Backlog.
• Le livre écrit « Development Team » ; depuis 2020, le Guide dit « Developers ».

Limites et pièges

Une Vision rédigée par la direction seule et affichée dans un couloir ne remplit pas la fonction décrite par le pattern, puisque personne ne se l'est appropriée.

Le Product Backlog se dégrade de deux façons courantes. Il devient un dépôt de plusieurs centaines de lignes que plus personne ne relit, ou bien il coexiste avec des listes parallèles, comme les « urgences » qu'un responsable transmet directement aux développeurs. L'ordre lui-même est faussé quand il reflète la voix la plus forte, ou quand tout est classé « priorité 1 ».

Les chiffres de valeur appellent de la prudence. Les auteurs reconnaissent que l'erreur d'estimation peut dépasser l'écart de valeur entre deux éléments. Ils rapportent aussi que, selon Jeff Sutherland, réordonner un backlog peut doubler la valeur obtenue : c'est une affirmation de praticien, que le livre n'appuie sur aucune mesure. Enfin, High Value First suppose que chaque morceau livré ait une valeur propre, ce qui n'est pas le cas quand un service n'est utile qu'une fois complet. L'article Critiques et état des preuves revient sur le statut de ces recommandations.