Product Owner et gestion du backlog : valeur, user stories et priorisation

Le plus difficile, quand on construit un logiciel, ce n'est pas de le construire. C'est de décider quoi construire, dans quel ordre et quoi laisser de côté, et de refaire cet arbitrage sans cesse à mesure que le marché, les utilisateurs et la réalité technique évoluent. C'est précisément cette décision que porte la responsabilité de product owner, et un product backlog n'est rien d'autre que la forme écrite, à un instant donné, de la réponse.

La plupart des backlogs échouent en tant que réponse. Ils accumulent toutes les demandes jamais formulées, sont ordonnés selon la dernière personne à s'être plainte et contiennent des éléments si flous que l'équipe doit deviner. Ce guide vise à faire travailler le backlog utilement : ce qu'exige réellement la responsabilité, comment rédiger des éléments qui valent la peine d'être construits, comment garder la liste affinée et comment l'ordonner de façon défendable. Le guide sur le framework Scrum couvre les événements qui consomment le backlog ; ici, on s'intéresse à ce qui les alimente.

Maximiser la valeur est une responsabilité, pas une liste de tâches

Le framework dit que le product owner est responsable de maximiser la valeur du produit issue du travail de l'équipe. Deux mots de cette phrase portent tout le poids. Maximiser suppose de choisir entre des options dont l'erreur a un vrai coût : un product owner doit donc pouvoir dire non, publiquement et souvent. Responsable suppose que l'organisation respecte effectivement ses décisions : si un directeur peut réordonner le backlog simplement en entrant dans la salle de l'équipe, la responsabilité n'est que nominale.

Trois éléments rendent cette responsabilité tenable en pratique. Le premier est une vision produit : une courte déclaration qui dit qui le produit sert, quel problème il résout pour ces personnes et en quoi il se distingue. Le deuxième est un product goal : le prochain objectif significatif sur ce chemin, assez concret pour qu'on sache quand il est atteint, et stable sur une durée supérieure à un sprint. Le troisième, ce sont les données : statistiques d'usage, volume du support, chiffre d'affaires, entretiens, expérimentations, tout ce qui transforme un débat de priorisation en discussion sur des mesures plutôt qu'en concours d'opinions.

Un product owner sans vision produit un backlog sans forme. Un product owner sans données en produit un ordonné par rang hiérarchique.

Rédiger des éléments qui résistent à l'épreuve de l'équipe

Le format de user story (en tant que <utilisateur>, je veux <capacité>, afin de <bénéfice>) est une convention, pas une règle issue d'un quelconque framework. Toute sa valeur tient dans la troisième proposition : elle oblige l'auteur à énoncer une raison, et une story dont le « afin de » est vide ou circulaire ne devrait généralement pas être construite. Le format est un point d'ancrage pour une conversation, pas une spécification ; c'est pourquoi un élément qui n'a jamais été discuté avec l'équipe n'est pas prêt, aussi bien rédigé soit-il.

La check-list INVEST est le test de qualité habituel d'un élément.

Les critères d'acceptation rendent concrète la dernière propriété. Ils doivent décrire un comportement observable, y compris les cas d'échec, et appartiennent à l'élément plutôt qu'à un document de test séparé. Un style par scénarios (étant donné un état initial, quand quelque chose se produit, alors on observe ceci) se lit naturellement et se traduit directement en tests automatisés : c'est la passerelle que formalise le BDD avec Cucumber. Limitez-vous à une poignée de critères ; vingt critères sur un seul élément signalent qu'il faut le découper.

Notez la différence avec la Definition of Done. Les critères d'acceptation sont propres à un élément et répondent à la question « avons-nous construit la bonne chose ? » ; la Definition of Done s'applique à tous les éléments et répond à « l'avons-nous construite correctement ? ». Confondre les deux produit des éléments qui satisfont leurs critères mais ne peuvent toujours pas être mis en production.

L'affinage, une activité continue

L'affinage (backlog refinement) est le travail permanent qui consiste à ajouter du détail, des estimations et un ordre aux éléments du backlog, pour que le haut de la liste soit toujours prêt à être sélectionné. Le framework le décrit comme une activité continue et non comme un événement, et ce n'est pas un détail : les équipes qui le réduisent à une unique réunion de quatre-vingt-dix minutes par sprint arrivent souvent au Sprint Planning avec des éléments auxquels personne n'a réfléchi.

L'affinage produit un haut de backlog prêt. Une Definition of Ready praticable : l'élément a été discuté avec les développeurs, possède des critères d'acceptation, n'a aucune dépendance externe non résolue, est assez petit pour être terminé en un sprint et porte une estimation qui convient à l'équipe. Deux ou trois sprints de tels éléments suffisent ; affiner plus loin est du gaspillage, car l'ordre de ce qui se trouve en dessous changera avant que vous n'y arriviez.

Quelques habitudes utiles : consacrez à l'affinage environ cinq à dix pour cent du temps de l'équipe ; affinez en équipe complète pour que testeurs et gens de l'exploitation repèrent les problèmes tôt ; timeboxez chaque élément et mettez de côté tout ce qui s'éternise pour une investigation séparée ; et découpez pendant l'affinage plutôt qu'au Sprint Planning, où l'on n'a plus le temps de réfléchir.

Ordonner le backlog

Ordonner le backlog est l'acte le plus lourd de conséquences du product owner, et aucune technique n'est la bonne dans toutes les situations.

Valeur contre effort. Placez chaque élément sur deux axes et traitez d'abord le quadrant valeur élevée, effort faible. C'est grossier, et c'est généralement suffisant, surtout pour un petit backlog dont tout le monde partage le contexte.

WSJF (weighted shortest job first). Un modèle de scoring popularisé par les frameworks d'agilité à l'échelle. On estime le coût du retard (cost of delay) comme la somme de trois scores relatifs (valeur pour l'utilisateur ou le métier, criticité temporelle, réduction du risque ou création d'opportunités), puis on le divise par la taille du travail. Une comparaison chiffrée :

Le correctif de recherche l'emporte alors qu'il est l'élément le moins porteur de valeur, parce qu'il est peu coûteux et réalisable tout de suite. C'est tout l'intérêt de la technique : elle favorise les travaux courts dont le coût du retard est significatif, et elle rend l'arbitrage assez explicite pour qu'on puisse en débattre. Sa faiblesse est la fausse précision : les entrées sont des estimations relatives, traitez donc le résultat comme une indication de classement plutôt que comme un calcul.

MoSCoW. Must, should, could, won't-this-time (indispensable, souhaitable, facultatif, pas cette fois). Utile face à une échéance fixe où c'est le périmètre qui doit s'ajuster, et pour la discipline qu'impose la quatrième catégorie. Son mode d'échec est bien connu : tout devient indispensable. Une règle courante veut que les « must » ne dépassent pas environ soixante pour cent de la capacité disponible.

Kano. Classe les fonctionnalités selon la manière dont la satisfaction y réagit : les attentes de base, dont l'absence provoque la colère mais dont la présence passe inaperçue, les fonctionnalités de performance linéaires, et les facteurs d'enchantement. C'est un bon correctif pour les backlogs remplis de facteurs d'enchantement alors qu'une attente de base, comme la réinitialisation du mot de passe, est cassée.

Utilisez-en une comme technique principale et les autres pour challenger le résultat. C'est aussi au moment d'ordonner qu'interviennent les dépendances et les risques : un élément dont une dépendance a un long délai d'obtention peut devoir démarrer plus tôt que sa seule valeur ne le justifierait, ce qui renvoie directement à l'estimation et à la planification.

Découper les gros éléments

Le découpage est la compétence qui améliore le plus le flux, car les petits éléments se terminent, et c'est en terminant qu'on obtient du feedback. La règle est de découper verticalement (chaque tranche traverse toutes les couches et livre quelque chose d'observable) plutôt qu'horizontalement par composant, ce qui produit quatre éléments et aucun logiciel fonctionnel avant l'arrivée du dernier.

Des patterns de découpage fiables :

• Par étape du parcours. Traitez d'abord le cas nominal de bout en bout ; ajoutez la validation, les cas limites et l'administration ensuite.
• Par règle métier. Une devise, un pays, un type de client d'abord ; généralisez ensuite.
• Par interface. Une API qui fonctionne avant l'écran soigné, ou un simple tableau avant le graphique interactif.
• Par variation de données. Gérez dès maintenant la forme d'enregistrement courante, les formats historiques rares ensuite.
• Par opération. Création et lecture avant mise à jour et suppression, si cet ordre correspond à l'usage réel.
• Spike puis réalisation. Quand un élément n'est pas estimable, détachez-en une investigation timeboxée, avec une question précise et une réponse écrite comme livrable.

Si une tranche ne peut pas être décrite comme quelque chose qu'un utilisateur remarquerait, il s'agit probablement d'une tâche et non d'une story, et elle a sa place à l'intérieur d'un autre élément.

Parties prenantes et roadmaps

Un product owner passe une part étonnante de sa semaine hors de l'équipe. Cartographiez les parties prenantes selon leur influence et leur intérêt, convenez de la façon dont chaque groupe est tenu informé, et faites passer les demandes par le backlog plutôt que par la boîte de réception de l'équipe. La Sprint Review est le principal canal planifié ; elle fonctionne mieux lorsqu'elle ressemble davantage à une vraie séance de travail sur la suite qu'à une démonstration en attente de validation.

C'est dans les roadmaps que l'honnêteté se perd le plus souvent. Une roadmap de fonctionnalités datées devient un ensemble de promesses qui n'ont jamais été des estimations, et chaque glissement devient un problème de crédibilité. Deux alternatives résistent mieux au changement : une roadmap par objectifs, qui nomme le résultat visé à chaque horizon plutôt que les fonctionnalités, et une roadmap now-next-later, où seule la colonne « now » porte des dates. Les deux permettent de changer le moyen sans rompre l'engagement. Quelle que soit la formule retenue, gardez-la visible dans le même outil que le backlog pour qu'elle ne puisse pas diverger en silence ; voir les outils de gestion de projet pour les compromis en la matière.

Points clés à retenir

• La responsabilité consiste à maximiser la valeur, ce qui exige l'autorité de dire non et une organisation qui respecte l'ordre établi.
• Un product goal donne une direction au backlog ; sans lui, les débats de priorisation n'ont aucune référence à laquelle se mesurer.
• Les éléments sont des points d'ancrage pour des conversations : INVEST et des critères d'acceptation concrets les gardent petits, porteurs de valeur et testables.
• L'affinage est continu, coûte environ cinq à dix pour cent du temps de l'équipe et doit maintenir en haut du backlog deux ou trois sprints de travail prêt, pas davantage.
• WSJF, MoSCoW, Kano et valeur contre effort mettent chacun en lumière un arbitrage différent ; choisissez-en un comme technique principale et servez-vous des autres pour challenger le résultat.
• Découpez verticalement pour que chaque tranche livre quelque chose d'observable, et placez les anomalies et le travail technique dans la même liste ordonnée que les fonctionnalités.