Le flux de valeur

Affiner le Product Backlog

Un Product Backlog bien ordonné ne suffit pas pour démarrer un Sprint. Il faut encore que les éléments du haut de la liste soient assez clairs et assez petits pour être réalisés sans mauvaise surprise. Cinq patterns d'A Scrum Book décrivent ce travail de préparation, appelé affinage, et la mesure à lui donner.

Lundi matin, devant une salle de bains

Le chantier était bien en tête de liste, mais il n'était pas prêt. Dans le vocabulaire de Scrum, la liste est le Product Backlog, chaque chantier est un Product Backlog Item (PBI, élément du Product Backlog) et la quinzaine est un Sprint. Le Product Owner est la personne responsable de la valeur du produit et de l'ordre de la liste, et les développeurs sont ceux qui réalisent le travail. Ce qui a manqué ici s'appelle l'affinage du Product Backlog. Jeff Sutherland, James Coplien et leurs coauteurs lui consacrent plusieurs patterns dans A Scrum Book (2019). Chaque pattern décrit un problème récurrent et une solution éprouvée par des praticiens.

Un travail régulier sur le haut de la liste

Le pattern Refined Product Backlog (Product Backlog affiné, aussi nommé Backlog Refinement Meeting) part d'une tension entre deux risques. Pour saisir une occasion au bon moment, l'équipe doit avoir compris le besoin et réuni ce qu'il faut pour démarrer. Mais préparer trop tôt un élément lointain coûte cher : le temps passé manque à des éléments plus proches, et le contexte aura changé avant qu'on y arrive. Les dépendances compliquent les choses, puisque certains éléments doivent être livrés avant d'autres. Enfin, ce que l'équipe apprend chaque semaine peut modifier le meilleur ordre.

La solution est que la Scrum Team, et surtout le Product Owner et les développeurs, se retrouvent fréquemment pour remettre le Product Backlog en ordre et découper les gros éléments qui approchent. Les développeurs tiennent leurs estimations à jour. L'attention se porte sur le haut de la liste, sur les dépendances entre éléments et sur les dates extérieures : une saison commerciale, la livraison d'un fournisseur ou la rentrée scolaire. Les éléments prévus pour les deux ou trois prochains Sprints doivent être assez petits pour qu'aucun ne représente plus de 10 % du travail d'un Sprint.

Pour ordonner selon les dépendances, les auteurs suggèrent une technique issue de l'ingénierie, la matrice de structure de conception (Design Structure Matrix). On inscrit les éléments en lignes et en colonnes, on coche les cases où l'un dépend de l'autre, puis on réordonne jusqu'à ce que chaque élément vienne après ceux dont il dépend. Si c'est impossible, deux éléments dépendent l'un de l'autre, et il faut les réexaminer ou les fusionner.

Le pattern attribue à l'affinage une seconde fonction. Découvrir un élément plusieurs semaines avant de le réaliser laisse aux développeurs le temps d'y réfléchir. Les auteurs s'appuient sur l'idée de « lente intuition » développée par Steven Johnson dans Where Good Ideas Come From (2010).

Sur le temps à y consacrer, ils donnent un repère : le Product Owner ne devrait pas mobiliser les développeurs plus de 10 % de leur temps de travail, et ces séances se planifient à l'avance au lieu d'être réclamées au fil de l'eau. Pour un Sprint de deux semaines à 35 heures, cela fait au plus 7 heures par personne, par exemple deux séances hebdomadaires d'une heure et demie, soit 6 heures par Sprint.

La Definition of Ready

Le pattern Definition of Ready (définition de « prêt », surnommée Ready-Ready) traite le problème de la salle de bains. Quand les développeurs comprennent mal un élément, l'effort enfle en cours de route et le Sprint manque son objectif. Plusieurs forces poussent pourtant à démarrer trop tôt. Une idée naît abstraite alors que la réalisation exige du concret. En réunion de planification, le groupe est tenté de remettre à plus tard les questions difficiles pour avancer. Le Product Owner raisonne en besoins et en marché, les développeurs en conception, et il faut un point de contact net entre ces deux mondes.

La solution est une courte liste de critères que tout élément doit remplir avant d'être candidat à un Sprint. Le pattern en propose six :

• l'équipe peut commencer le travail immédiatement ;
• le livrable prévu a de la valeur ;
• le Product Owner et les développeurs en ont discuté ;
• les développeurs l'ont estimé ;
• il est vérifiable, et le Product Owner a précisé comment on le vérifiera ;
• il est de taille convenable.

Un Product Backlog est dit « Ready » quand il contient en tête assez d'éléments conformes pour remplir un Sprint. Les auteurs conseillent d'ajouter un critère sur les dépendances extérieures, car un élément qui attend quelque chose hors du contrôle de l'équipe met tout le Sprint en danger. Pour le chantier de Mme Lefèvre, la liste deviendrait : devis signé, matériaux choisis et commandés avec une date de livraison, visite technique faite, durée estimée par les artisans, et critères de réception convenus avec la cliente.

Le pattern précise que seuls les éléments proches du haut de la liste ont besoin d'être prêts, et que le but est qu'ils franchissent ce seuil sans s'y arrêter. Si un élément n'est pas prêt, il revient d'abord au Product Owner de reprendre son analyse. Les auteurs rappellent une tradition racontée par Jeff Sutherland dans Scrum: The Art of Doing Twice the Work in Half the Time (2014) : devant un backlog qui n'est pas prêt, les développeurs auraient le droit d'aller à la plage. Ils la tempèrent aussitôt en demandant aux développeurs comment ils peuvent aider le Product Owner. Selon eux, la première description formelle de cette pratique semble due à Richard Kronfält, en 2008.

Enabling Specification : assez d'information pour avancer sans redemander

Le pattern Enabling Specification (spécification habilitante) s'attaque à une habitude née avec les méthodes agiles : jeter une idée dans le Product Backlog en se disant que les détails viendront plus tard. Scrum accepte que des besoins apparaissent en chemin, et l'on peut être tenté d'en conclure qu'ils se révéleront tous pendant la réalisation. Les auteurs objectent que réaliser pour découvrir un besoin est un moyen lourd, quand une conversation avec un usager aurait suffi. La plupart des dérapages de calendrier viennent, selon eux, d'une analyse insuffisante ou mal transmise.

La solution est que le Product Owner apporte, pour chaque élément proche, une spécification assez riche pour qu'une personne compétente dans le métier puisse réaliser une solution sans demander d'éclaircissement important hors de la Scrum Team. L'expression vient du droit des brevets, où un brevet n'est valable que s'il permet à une personne du métier de reproduire l'invention sans consulter l'inventeur. Les développeurs gardent le dernier mot : s'ils estiment ne pas en savoir assez, ils ne prennent pas l'élément dans le Sprint.

Les auteurs précisent que la spécification compte moins par ce qui est écrit que par ce que l'équipe a compris. Elle se construit par des échanges, des exemples et des maquettes, et le document sert surtout d'aide-mémoire. Une bonne spécification comporte des critères de vérification écrits.

Petit en haut, gros en bas

Small Items

Le pattern Small Items (petits éléments) part d'un constat : les grandes idées sont faciles à avoir, mais les gros éléments sont difficiles à comprendre, à estimer et à finir. Une erreur de 20 % sur un travail de vingt jours représente quatre jours, alors qu'elle représente moins d'une demi-journée sur un travail de deux jours. Un gros élément risque de ne pas être terminé à la fin du Sprint, et l'équipe n'a alors rien à montrer ni aucun retour à recueillir. Quand chaque tâche dure plusieurs jours, le Daily Scrum, le point quotidien de l'équipe, n'apprend plus rien à personne.

La solution est de découper le travail en éléments que les développeurs comprennent bien et terminent vite. Pour les tâches du plan de travail du Sprint, les auteurs recommandent deux jours au maximum. Ils précisent que le but premier est la compréhension et que la précision des prévisions vient ensuite : découper oblige à concevoir, et c'est en concevant que l'on comprend. En contrepartie, l'équipe passe plus de temps à affiner et gère davantage d'éléments.

Granularity Gradient

Tout découper finement serait un gaspillage, et c'est le problème du pattern Granularity Gradient (gradient de granularité). Découper demande du travail, et plus un élément est lointain, plus il a de chances de changer ou de disparaître. Les auteurs citent Barry Boehm (Software Engineering Economics, 1981), selon qui une estimation peut être fausse d'un facteur allant jusqu'à quatre tant que les besoins ne sont pas détaillés. Ils signalent un second risque : des estimations très fines donnent à qui le souhaite un moyen de surveiller les développeurs heure par heure.

La solution est de proportionner la taille des éléments à leur profondeur dans la liste. Pour les deux ou trois prochains Sprints, aucun élément ne devrait dépasser 10 % du travail d'un Sprint, et 5 % est préférable. Au-delà de quatre ou cinq Sprints, un élément peut être de taille quelconque et n'exprimer guère plus qu'une intention. Tous restent estimés, mais on rafraîchit moins souvent les estimations lointaines.

Ce que dit le Guide Scrum 2020

Les patterns vont plus loin que le Guide Scrum, et plusieurs de leurs repères n'y figurent pas.

• Le Guide décrit l'affinage comme une activité continue qui consiste à découper et à préciser les éléments, en leur ajoutant une description, un ordre et une taille. Il n'en fait pas un événement, ce que le livre signale lui-même.
• Le plafond de 10 % du temps des développeurs figurait dans l'édition 2017 du Guide. L'édition 2020 ne le mentionne plus.
• Le Guide ne contient pas de « Definition of Ready ». Il indique seulement que les éléments réalisables en un Sprint sont considérés comme prêts à être sélectionnés au Sprint Planning, la réunion qui ouvre chaque Sprint.
• Le Guide confie l'estimation de la taille aux développeurs qui feront le travail, et le Product Owner peut les aider à comprendre les compromis.
• Le terme Enabling Specification est propre au livre, qui écrit par ailleurs « Development Team » là où le Guide 2020 dit « Developers ».

Limites et pièges

Le piège le plus courant est de transformer la Definition of Ready en barrière. Les développeurs refusent alors tout élément qui ne coche pas chaque case, le Product Owner rédige des documents de plus en plus épais pour se couvrir, et l'on retrouve le découpage en phases successives que Scrum voulait éviter. Le pattern prévient ce risque en demandant une liste courte et un passage sans arrêt, mais l'histoire de la plage se prête à une lecture conflictuelle.

L'excès d'affinage est un autre défaut. Des éléments détaillés des mois à l'avance forment un stock de décisions qui vieillissent. Le défaut inverse se voit au Sprint Planning, qui se transforme en longue séance de découverte parce que personne n'a regardé les éléments auparavant.

Le découpage lui-même peut mal tourner. Découper par métier ou par couche technique (toute la plomberie, puis tout le carrelage) produit des morceaux dont aucun n'a de valeur seul. Un petit élément doit rester un livrable que quelqu'un peut utiliser ou vérifier.

Enfin, les seuils cités ici (10 %, deux jours, deux à trois Sprints) sont des repères tirés de l'expérience des auteurs, et les travaux de Boehm concernent le logiciel. Aucun n'a été validé par des essais comparatifs. L'article Critiques et état des preuves précise ce que l'on sait et ce que l'on ignore.