Agile smells – Backlog et user stories

Suite de la série d’articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d’horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Aujourd’hui, parlons du backlog et des user stories…

Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :

• Agile smells – Management visuel
• Agile smells – Sprint planning
• Agile smells – Sprint daily stand-up meeting
• Agile smells – Sprint review
• Agile smells – Sprint retrospective
• Agile smells – Pratiques de développement et de test
• Agile smells – Rôles et motivation

Les éléments du backlog sont des user stories priorisées, détaillées et estimées pour les 12 prochaines itérations

La situation

Les users stories définies dans le backlog de l’équipe ont toutes été revues lors de réunions d’affinage. Elles ont des critères d’acceptation, des exemples associés, une première analyse technique et des estimations, ce qui signifie qu’en l’état, elles pourraient être développées à n’importe quel moment.

Au total, en comptant des itérations d’une durée de deux semaines, le backlog est donc entièrement détaillé pour les six prochains mois.

Pourquoi ça sent mauvais ?

La vie d’un produit est souvent faite de remous, et le contexte (besoins utilisateur, budget, etc.) qui avait permis l’émergence des premières idées peut être amené à changer de manière plus ou moins radicale. Deux cas de figure se présentent alors :

• Le suivi du plan initial

Le risque principal est un réflexe naturel consistant à s’accrocher contre vents et marées au planning initialement défini. En effet, une feuille de route ayant été établie via un énorme travail, les personnes concernées auront tendance à suivre aveuglement ce plan pour justifier le temps passé dessus, plutôt que de profiter des opportunités de changement. Le produit s’éloigne alors des réels besoins des utilisateurs, réduisant ainsi son intérêt.

• Le pivot

Un choix plus raisonnable est de pivoter à un moment donné afin de prendre une direction plus en adéquation avec les nouveaux besoins qui ont émergé. La conséquence directe est alors de devoir déprioriser une bonne partie des user stories, et donc perdre de nombreuses heures de travail passées sur de l’analyse et de l’écriture.

Dans tous les cas, du temps, et donc de l’argent, ont été passés sur des hypothèses n’aboutissant finalement à rien, plutôt que sur des développements de fonctionnalités immédiatement livrées.

Enfin, au-delà du travail centré sur les besoins utilisateur et les possibles pivots, un backlog composé d’éléments détaillés sur une si grande période de temps, se construit au travers d’un gros effort d’affinage, et donc d’analyse technique. Or, de la même manière qu’un besoin utilisateur peut évoluer, une architecture technique qui était justifiée à un instant t peut se révéler être obsolète quelques mois plus tard. En effet, l’architecture d’un projet agile est en perpétuelle évolution par le fait qu’elle émerge à chaque itération. Les nombreuses heures de travail passées sur de l’analyse technique seront donc elles aussi perdues.

Concrètement on fait quoi ?

Une méthode simple et efficace pour la tenue d’un Product Backlog est représentée par le schéma suivant :

Cette pyramide, également appelée Product Backlog Iceberg, se découpe en trois parties :

• L’essentiel des grandes fonctionnalités qui servent à construire la roadmap du produit sont représentées par des Epics. Généralement elles sont issues des premières discussions avec les utilisateurs finaux et ne sont pas forcément encore validées ni analysées.

• Lorsqu’une ou plusieurs Epics sont priorisées pour être dans la prochaine release, elles vont être affinées avec l’aide des utilisateurs pour le découpage en Features, qui vont faire l’objet d’une première analyse technique. L’idée de cette analyse est surtout de voir rapidement la faisabilité technique, et dans des cas plus rares, de réaliser des prototypes.

• Les Features les plus prioritaires de la release seront de nouveau découpées en user stories respectant le principe INVEST pour les deux ou trois prochaines itérations. L’idée ici étant d’avoir un stock de user stories prêtes à être intégrées à n’importe quel moment.

Autrement dit, plus on s’éloigne dans le temps, moins le niveau de détails est important. On pourrait faire un parallèle avec un mantra issu de l’Extreme Programming : YAGNI (You Aren’t Gonna Need It), qui se résume à ne pas faire quelque chose qui ne serait utile que dans un hypothétique futur.

« Alors aujourd’hui j’ai seulement deux stories à vous présenter »

La situation

Une équipe de trois développeurs s’engagent sur le périmètre d’une itération ne comportant que deux user stories.

Pourquoi ça sent mauvais ?

Chaque itération comporte son lot de surprises : un bug de production urgent à corriger, un impact non anticipé ou encore une absence non prévue, qui sont autant de chances de ne pas réussir à terminer une user story avant la fin de l’itération. Le problème en ne s’engageant que sur deux grosses user stories, est que si une story n’est pas terminée, c’est la moitié de l’itération qui n’est pas terminée.

Les conséquences sont diverses :

• La vélocité de l’équipe est complexe à estimer : des user stories étant régulièrement reportées d’une itération à l’autre, l’équipe a une vélocité en dents de scie, ce qui rend difficile d’établir une quelconque prévision pour un plan de release par exemple.
• L’équipe essuie régulièrement des échecs : ne pas réussir à tenir ses engagements de manière régulière peut s’avérer être une source de démotivation pour les membres de l’équipe.

Cette situation est parfois jumelée à une autre situation qui aurait pu faire l’objet d’un smell à part entière : lorsqu’en Sprint Planning, quelqu’un répond à une remarque sur la taille de la story de la manière suivante : « Ce n’est pas grave si on ne la termine pas là, elle sera finie l’itération prochaine. L’important c’est juste qu’elle soit finie au bout du compte. ».

Concrètement on fait quoi ?

Tout simplement, lisez l’article écrit par Meriem El Aaboudi et Frédéric Courdier. Si vous manquez de courage pour cliquer sur le lien, voici un très court résumé des avantages de découper en petites user stories :

• Réduire le temps de cycle : une story plus petite sera sujette à un feedback plus rapidement car elle sera terminée plus tôt.
• Faciliter l’adaptation au changement : si un moindre imprévu survient, plus la story sera petite, moins l’impact sera important.
• Réduire l’incertitude et le risque : estimer la complexité d’un petit périmètre (par exemple la création d’un formulaire d’identification) est toujours plus simple que d’estimer la complexité d’une grosse fonctionnalité (comme la mise en place de toute la partie sécurité d’un site).
• Satisfaire l’équipe régulièrement : chaque user story terminée est une petite victoire, et chaque victoire apporte une dose de satisfaction personnelle. Neuf victoires sur dix, valent donc mieux qu’une sur deux.

L’article termine par un extrait de la règle six de la Scrum Master Academy qu’il est important d’avoir en tête : « Il faut pouvoir prendre plus de 4 user stories par sprint ». Idéalement, il faudrait même « qu’un développeur puisse travailler sur plus d’une story pendant le sprint » pour limiter le risque de report à l’itération suivante.

Enfin, l’article met à disposition des liens très utiles vers des techniques de découpage de user story (oui vous allez finalement être obligé de cliquer sur le lien).

« T’as lu les critères d’acceptation ? » – « Euh pas vraiment… Ils sont où déjà ? »

La situation

Un développeur appelle le Product Owner pour valider une user story qu’il considère implémentée. Le Product Owner s’aperçoit rapidement que certaines fonctionnalités ne répondent pas aux besoins qu’il avait exprimé. En réalité, les critères d’acceptation n’ont pas été entièrement respectés et aucun test associé n’a été réalisé.

Pourquoi ça sent mauvais ?

Cette situation est symptomatique d’un fonctionnement d’équipe qui n’est pas clairement défini : chaque membre de l’équipe va avoir sa vision de la manière dont doit se dérouler le développement d’une user story, ainsi que ce qui va définir que celle-ci est prête à être envoyée en production.

Lorsqu’un développeur, pensant de manière sincère avoir terminé ses développements, présente le fruit de son travail à un Product Owner qui s’attend à un autre résultat, cela va engendrer une déception plus ou moins importante. Si l’on ajoute à cela, les quelques allers-retours qu’il y aura avant que la fonctionnalité ne soit considérée comme bonne, la vision du Product Owner sur l’équipe de développement va se retrouver écornée et une perte de confiance va progressivement s’installer.

À partir du moment où le Product Owner perd confiance dans la qualité du travail fourni par l’équipe, il va devenir méfiant et cela se fera ressentir fortement par l’équipe avec un Product Owner qui aura tendance à surveiller d’un peu trop près le déroulement des développements.

L’exemple entre un Product Owner et un développeur peut s’appliquer de la même manière directement entre développeurs sur divers sujets, que ce soit sur les tests ou sur la qualité du code. Dans tous les cas, perte de confiance et méfiance s’installeront au quotidien, créant ainsi une ambiance peu propice au travail d’équipe et à l’entraide.

Concrètement on fait quoi ?

Pour aligner tous les membres de l’équipe sur un niveau d’exigence minimum requis afin d’amener une user story en production et éviter ainsi des déceptions inutiles, il suffit de réunir toute l’équipe et de la faire arriver à un consensus sur une liste de critères qui devront être respectés avant de considérer une user story terminée.

Généralement appelée Definition of Done, cette liste permet de faire des vérifications sur plusieurs aspects :

• Qualité : le code a été vu par plusieurs développeurs, il respecte des standards définis par l’équipe, etc.
• Test : un seuil minimum de couverture de code est défini, les tests de non régression sont ok, les tests d’acceptation associés ont été automatisés, il existe si besoin un test de performance, etc.
• Déploiement : la fonctionnalité a été déployée sur un environnement, etc.

Bien évidemment, la validation par le Product Owner vient s’ajouter à cette liste, mais si tous les critères ont été respectés, cette validation se passe généralement sans trop de problème.

Enfin, faire une liste est un bon début, l’afficher publiquement de manière à ce que tout le monde puisse la voir et s’y référer régulièrement lorsqu’une user story est annoncée comme terminée, est également le meilleur moyen de ne pas l’oublier.

« Mais ça sort d’où ça ? » – « Ah oui j’ai dû oublier de vous le dire… Mais c’est super important, je ne peux pas valider sans l’avoir »

La situation

Le Product Owner a présenté, lors du Sprint Planning, une user story qui n’était pas très claire. Durant l’itération, les développeurs responsables de cette user story vont régulièrement poser des questions au Product Owner pour avoir des éclaircissements. Pensant avoir enfin terminé la user story, ils la passent en revue avec le Product Owner afin de la faire valider définitivement. Seul problème, le Product Owner émet des remarques bloquantes qu’il avait omis de présenter auparavant.

Pourquoi ça sent mauvais ?

Dissipons en premier lieu tout doute qui pourrait apparaître : non, ne pas avoir fait de spécification détaillée n’est pas le problème dans cette situation. Une user story avec un niveau de détail trop élevé nécessitera un travail plus important en amont de l’itération ce qui engendrera un temps de cycle, entre le moment où la user story est créée et le moment où elle est terminée, trop long. Cela réduira également les développeur à un rôle de simple exécutant, tout ayant déjà été défini.

Au contraire, une user story sans assez de détail, comme dans la situation présente, impliquera des phases de découvertes importantes durant l’itération. Le risque étant de se retrouver dans la situation d’un arbre cachant la forêt et donc des user stories impossibles à terminer durant l’itération. On se retrouve alors dans les mêmes dangers que pour le deuxième smell de cet article : une vélocité impossible à prédire et une succession d’échecs ressentis par l’équipe, ce qui influencera négativement la motivation ainsi que la confiance accordée au Product Owner.

Un des premiers réflexes sera alors de surestimer la complexité de toutes les user stories afin de compenser d’éventuels imprévus. Au final, un remède contre les symptômes mais pas contre l’origine du problème.

Concrètement on fait quoi ?

Pour définir correctement le périmètre d’une user story sans pour autant tomber dans la rédaction d’un document d’une dizaine de pages, il est nécessaire de définir des critères d’acceptation. En d’autres termes, définir un ensemble de conditions qui doivent être satisfaites pour considérer que la user story a bien atteint son objectif. Ces critères prennent généralement la forme d’exemples de comportement (obtenus par exemple en pratiquant le BDD) et sont souvent associés au langage Gherkin :

• Given : l’état du produit avant exécution de la user story
• When : l’action de déclenchement de l’exécution
• Then : l’état du produit attendu après l’exécution de la user story

Une simple série de critères d’acceptation univoques va suffire à cadrer le périmètre d’une user story et sera en plus un élément fondamental pour la mise en place de l’automatisation des tests d’acceptation.

Nous avons vu ici une manière de définir les comportements attendus d’une user story, mais d’autres éléments peuvent entrer en compte. C’est pourquoi, de la même manière qu’une équipe à besoin de définir une Definition of Done, elle va avoir besoin de définir une Definition of Ready, à savoir, un niveau d’exigence minimum requis afin d’intégrer une user story dans une itération. Et la recette est la même : l’équipe se réunit et arrive à un consensus sur une liste de critères qui devront être respectés avant de considérer une user story comme prête à être développée. Cela permettra d’effectuer des vérifications sur plusieurs aspects :

• Formalisme commun : la user story suit le formalisme « En tant que… Je veux… Afin de… », etc.
• Définition : des critères d’acceptation existent, des critères de performance, si nécessaire, ont été définis, l’équipe sait comment démontrer la user story, etc.
• Gestion des pré-requis : les dépendances, si existantes, ont été livrées et testées, les jeux de données sont disponibles, etc.
• Analyse technique : l’équipe a déjà fait une première analyse aboutissant à une estimation de la complexité, etc.

Bien évidemment cette liste va servir de base de réflexion lors du Sprint Planning pour savoir si l’équipe a suffisamment d’éléments pour s’engager sur la réalisation. Le refus d’une user story doit forcément être accompagné d’un plan d’action en équipe pour faire en sorte d’être capable de prendre cette user story lors d’une prochaine itération, sinon, sur le long terme, le Product Owner risque d’avoir du mal à accepter ce genre de situation.

Enfin, il est nécessaire de prendre du recul régulièrement en équipe afin de valider que le niveau de détail des user stories des itérations précédentes doit être reconduit ou modifié dans le futur.

Conclusion

Au travers de quatre situations, nous avons découvert comment le backlog et les user stories pouvaient révéler des pratiques contre-productives, mais également, comment ils pouvaient être une aide d’une grande efficacité pour améliorer de nombreux aspects de la vie d’une équipe. Pour ceux qui le souhaitent, vous pouvez retrouver plusieurs articles détaillés sur ces sujets dans la Product Academy. Ne jetez pas votre désodorisant tout de suite, nous revenons bientôt avec de nouveaux agile smells dédiés cette fois-ci aux pratiques de développement et de test.