Méthodes et pratiques

User stories, backlog et estimation

Pour dire à une équipe ce qu'elle doit construire, la réponse classique est un cahier des charges détaillé. Les méthodes agiles lui préfèrent de courts récits écrits du point de vue de l'utilisateur, les user stories, rangés dans une liste ordonnée, le backlog. Cet article présente ces deux outils, les techniques d'estimation qui les accompagnent et le débat que ces estimations suscitent.

Une fiche et dix minutes de discussion

Une commune veut que les parents puissent payer la cantine en ligne. Hélène, la responsable du service scolaire, a écrit une phrase sur une fiche cartonnée : « En tant que parent, je veux payer la facture de cantine par carte bancaire, afin de ne plus envoyer de chèque. » Elle la présente à l'équipe de développement.

Malik, un développeur, pose la première question : « Un parent qui a trois enfants reçoit trois factures ou une seule ? » Hélène répond : « Une par enfant, mais il voudra sûrement tout régler en une fois. » La testeuse enchaîne : « Et s'il ne veut payer qu'une partie de la somme ? » Hélène n'y avait pas pensé. Elle interroge la trésorerie et revient le lendemain avec la réponse : le paiement partiel n'est pas accepté.

En dix minutes, la discussion a fait apparaître deux règles que la fiche ne contenait pas. Hélène note au dos comment on vérifiera que le travail est fini : une facture de 46,80 euros réglée par carte apparaît comme payée, et le parent reçoit un reçu par courriel. Cette fiche est une user story, littéralement un « récit utilisateur » : la description courte d'un besoin, formulée du point de vue de la personne qui l'éprouve.

Ce qu'est une user story

Une technique venue d'XP

Les stories apparaissent à la fin des années 1990 dans Extreme Programming, sur le projet C3 de Chrysler. Dans le « jeu du planning » que Kent Beck décrit en 1999, le client écrit sur des cartes ce que le système doit faire, et les programmeurs estiment chaque carte. La formule en trois temps, « En tant que… je veux… afin de… », est généralement attribuée à l'équipe de la société londonienne Connextra, où travaillait Rachel Davies, vers 2001. Mike Cohn l'a fait connaître dans User Stories Applied (2004).

La troisième partie de la formule est la plus utile, car connaître la raison permet à l'équipe de proposer mieux. Si le but est de ne plus envoyer de chèque, un prélèvement automatique répondrait peut-être au besoin plus simplement qu'un paiement par carte.

Carte, conversation, confirmation

Ron Jeffries, l'un des signataires du Manifeste, a résumé en 2001 ce qui fait une story par trois mots.

• La carte. Le besoin tient en quelques mots sur un support volontairement petit. Une formule attribuée à Alistair Cockburn fait de la carte la promesse d'une conversation.
• La conversation. Le détail se trouve dans l'échange entre ceux qui demandent et ceux qui réalisent, et cet échange reprend à chaque étape du travail.
• La confirmation. Des tests d'acceptation convenus d'avance diront si la story est terminée. On parle aussi de critères d'acceptation.

Ce choix met en pratique le sixième principe du Manifeste :

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Manifeste agile, principe 6 (texte intégral)

La story ne supprime pas l'écrit pour autant : la carte et les critères d'acceptation gardent la trace de ce qui a été convenu.

INVEST et l'art de découper

Bill Wake a proposé en 2003 un moyen mnémotechnique pour juger la qualité d'une story. Les six lettres du mot INVEST désignent six qualités.

• Indépendante : elle peut être réalisée sans attendre une autre story.
• Négociable : elle n'est pas un contrat, et ses détails se discutent.
• Valeur : elle apporte quelque chose à un utilisateur ou au client.
• Estimable : l'équipe en comprend assez pour évaluer le travail.
• Small (petite) : elle tient largement dans une itération, c'est-à-dire un cycle de travail de durée fixe.
• Testable : on sait dire comment vérifier qu'elle est terminée.

La taille est le critère qui demande le plus de savoir-faire. Une story trop grosse, parfois appelée « epic », doit être découpée, et la tentation est de la découper par couches techniques : d'abord la base de données, puis les traitements, puis l'écran. Aucune de ces tranches n'est utilisable seule, et l'on ne saura qu'à la fin si l'ensemble fonctionne. Les praticiens recommandent des tranches « verticales », dont chacune traverse toutes les couches et livre un résultat mince mais utilisable.

Pour la cantine, Hélène et l'équipe retiennent quatre stories : consulter le montant dû, payer une facture par carte, recevoir un reçu par courriel et payer plusieurs factures en une fois. Dès la deuxième, le site rend le service attendu à la plupart des familles, et la commune peut l'ouvrir sans attendre les deux autres.

Le backlog, une liste ordonnée et jamais finie

Le backlog est la liste de tout ce qui reste à faire sur un produit. Scrum l'appelle Product Backlog et confie son ordre au Product Owner. Deux traits le distinguent d'un cahier des charges. Il est ordonné, d'abord : chaque élément a un rang, et deux demandes ne peuvent pas être toutes deux « priorité 1 ». Il n'est ensuite jamais terminé, puisque l'on y ajoute des éléments, que l'on en retire et que l'on en change l'ordre à mesure que l'on apprend.

Le niveau de détail varie avec la position dans la liste. Les éléments du haut, que l'équipe réalisera dans les prochaines semaines, sont petits et précis. Ceux du bas restent grossiers, car les détailler maintenant serait du travail perdu s'ils changent ou disparaissent. L'affinage du backlog (refinement) est l'activité régulière qui consiste à découper, à préciser et à estimer les éléments qui approchent du haut.

Estimer : points, poker et vélocité

Pour décider de l'ordre et prévoir une date, il faut une idée du coût de chaque story. Les équipes agiles estiment le plus souvent de façon relative. Au lieu de dire qu'une story prendra trois jours, elles disent qu'elle est à peu près deux fois plus grosse qu'une autre, déjà réalisée. L'unité de cette mesure est le « point de story ». Ron Jeffries raconte que les points sont nés dans XP : l'équipe estimait en « jours idéaux », c'est-à-dire en jours sans interruption, et elle les a rebaptisés « points » parce que les commanditaires s'étonnaient qu'un jour idéal prenne environ trois jours réels.

Le planning poker, décrit par James Grenning en 2002 et popularisé par Mike Cohn dans Agile Estimating and Planning (2005), organise cette estimation. Chaque membre de l'équipe dispose de cartes dont les valeurs s'espacent de plus en plus, par exemple 1, 2, 3, 5, 8, 13 et 20. Après discussion de la story, chacun choisit une carte en secret, puis tous la retournent en même temps. Si les valeurs divergent, ceux qui ont donné la plus basse et la plus haute expliquent leur raisonnement, et l'on recommence. La révélation simultanée évite que le premier chiffre prononcé n'attire tous les autres, un effet que les psychologues appellent l'ancrage. L'écart entre les cartes est souvent plus instructif que la valeur retenue : quand l'un dit 2 et l'autre 13, ils n'ont pas compris la même story.

La vélocité est la somme des points des stories terminées pendant une itération. Elle sert à prévoir.

Quelques études ont comparé le planning poker à d'autres manières d'estimer. L'une d'elles, menée par Kjetil Moløkken-Østvold et ses collègues sur un projet réel et publiée en 2008, a trouvé des estimations de groupe moins optimistes et plus exactes que la simple moyenne des estimations individuelles. Ces travaux sont peu nombreux et de petite taille : ils rendent la technique plausible, sans plus.

Faut-il encore estimer ?

Depuis 2012, un courant réuni autour du mot-clé #NoEstimates, lancé par Woody Zuill et porté aussi par Neil Killick et Vasco Duarte, qui en a tiré un livre, conteste l'utilité de ces estimations. Son argument tient en peu de mots. Si les stories sont découpées assez finement pour être toutes à peu près de la même taille, il suffit de les compter. Une équipe qui termine en moyenne six stories par itération, et à qui il en reste trente, en a pour environ cinq itérations, sans avoir passé une heure à attribuer des points.

Ron Jeffries lui-même a pris ses distances. Dans un texte de 2019, il écrit qu'il a peut-être inventé les points de story et qu'il le regrette, parce qu'ils servent trop souvent à comparer les équipes et à faire pression sur elles. Les défenseurs de l'estimation répondent qu'une organisation doit décider si un projet vaut son coût avant de le lancer, et qu'il lui faut pour cela un ordre de grandeur. Le débat n'est pas tranché.

Hors du logiciel

La story est née dans le logiciel, mais sa forme convient à tout travail fait pour quelqu'un.

Limites et pièges

La carte sans la conversation. Dans beaucoup d'organisations, la story est devenue un formulaire dans un outil de suivi. Une personne la rédige seule, avec dix critères d'acceptation, puis l'envoie à l'équipe. On retrouve alors le cahier des charges, découpé en petits morceaux, et l'on perd l'échange qui faisait l'intérêt de la technique.

La formule appliquée mécaniquement. « En tant que développeur, je veux une table dans la base de données » respecte la syntaxe et ne décrit aucun besoin d'utilisateur. Quand la formule n'aide pas à réfléchir, une phrase ordinaire fait aussi bien.

Les détails qui cachent l'ensemble. Cent petites stories dans une liste ne disent pas à quoi ressemble le produit ni par où passe l'utilisateur. Jeff Patton a proposé pour cette raison, dans User Story Mapping (2014), de disposer les stories sur une carte qui suit le parcours de l'utilisateur.

La vélocité prise pour objectif. Dès qu'une direction demande à une équipe d'augmenter sa vélocité, les estimations gonflent et le chiffre monte sans que rien de plus soit livré. C'est un cas d'école de la loi de Goodhart. Comparer les vélocités de deux équipes n'a pas davantage de sens, puisque chacune a son propre étalon.

Des pratiques peu étudiées. Les user stories, les critères INVEST et le découpage en tranches verticales reposent sur l'expérience de praticiens. La recherche les a peu évalués, et l'article critique du corpus revient sur ce que l'on sait vraiment.