Une User Story est-elle éphémère ?
Et le mythe de la documentation inexistante en agilité
On m’a posé diverses questions autour des User Stories…
Lorsqu’on est en mode produit, est-ce que le cycle de vie d’une User Story s’arrête à la fin du Sprint (done) ? Ou est-ce qu’une User Story représente une unité fonctionnelle du produit, et sera donc rouverte en cas d’évolution fonctionnelle ?
Ce qui reviendrait à poser la question “est-ce que les User Story sont des éléments jetables une fois traitées par un sprint ?” ou “est-ce que les US qui sont ‘done’ sont finalement une sorte de spécification du produit, qui mérite d’être mise à jour s’il y a évolution ?”
Pour essayer de donner plus de matière, voici plusieurs choses m’ont amené à me poser ces questions :
▶ Vu que nous développons un nouveau produit, nous tâtonnons le fonctionnel. Et par conséquent, nous repassons souvent sur des features qui semblaient à priori terminées. Et c’est plus souvent pour les modifier que pour ajouter. Pourtant nous créons à chaque fois de nouvelles User Story. Au début ça ressemblait à un descriptif du fonctionnement souhaité, mais à la longue ça ressemble à un “diff” entre le comportement actuel et le comportement souhaité. Est-ce toujours une User Story du coup ? Intuitivement je me dis qu’il y a un problème.
▶ Pareil pour les “bugs de prod”. Un élément n’était pas dans les critères d’acceptation, car nous n’avions pas de recul, mais au final c’est important pour le/les clients. Du coup ça donne une nouvelle User Story pour un petit ajout qui aurait clairement fait partie de l’User Story initiale si on l’avait identifié. Ce mode de fonctionnement me parait étrange. Nos US ressemblent plus à un “diff” fonctionnel qu’à du descriptif d’une feature je trouve. Mais je ne vois pas comment l’éviter.
▶ Enfin la gestion des tests automatisés : en effet la plupart des outils de gestion des tests semblent mettre en avant le fait de lier les “requirements” avec les “tests”. Sauf que vu que le fonctionnel est disséminé entre toutes les User Stories qu’on a du créer au fil des sprints, le lien avec les tests n’est pas évident vu qu’il n’y a pas d’US de “référence”.
Finalement je ne sais pas si je suis à côté de la plaque à cause d’un élément d’incompréhension. Ces problématiques sont-elles couvertes par Scrum ? Auquel cas je me demande comment font les éditeurs de logiciel qui fonctionnent en agile sur ces problématiques !?!?
Ces questions sont orientées par rapport à ma situation actuelle, mais je me suis posé exactement les mêmes questions lors de mes précédentes expériences agiles. Mise à jour tickets versus création de tickets éphémères à chaque fois qu’il faut “faire quelque chose”.
Répondons point par point…
Une User Story est un élément de travail et non de documentation
Lorsqu’on est en mode produit, est-ce que le cycle de vie d’une User Story s’arrête à la fin du Sprint (done) ? Ou est-ce qu’une User Story représente une unité fonctionnelle du produit, et sera donc rouverte en cas d’évolution fonctionnelle ?
Oui le cycle de vie d’une User Story s’arrête lorsqu’elle est done. On ne la rouvre pas en cas d’évolution fonctionnelle ; on fera une nouvelle User Story. Une User Story est un élément de *travail* et non de *documentation*.
Les User Stories sont jetables et ne constituent pas la spécification du produit
Est-ce que les User Story sont des éléments jetables une fois traitées par un sprint ? Est-ce que les US qui sont ‘done’ sont finalement une sorte de spécification du produit, qui mérite d’être mise à jour s’il y a évolution ?
Donc oui les User Stories sont des éléments jetables. Elles ne forment pas la spécification du produit. Elles ne remplacent pas la nécessité d’écrire et maintenir la documentation du produit.
Une User Story doit décrire un besoin d’un point de vue utilisateur
Nous repassons souvent sur des features qui semblaient à priori terminées. C’est plus souvent pour les modifier que pour ajouter. Pourtant nous créons à chaque fois de nouvelles User Story. Au début ça ressemblait à un descriptif du fonctionnement souhaité, mais à la longue ça ressemble à un “diff” entre le comportement actuel et le comportement souhaité. Est-ce toujours une User Story du coup ?
Les User Stories ressemblent à des « diff » ? Mais à quoi donc ressemblent ces User Stories ?
Une User Story doit décrire un besoin d’un point de vue utilisateur. Focalisez-vous donc sur la valeur qu’apporte ce changement, plutôt que sur le fonctionnel existant. Dit autrement : pourquoi veut-on faire ce changement ?
Il n’y a pas que les User Stories dans la vie
Est-ce toujours une User Story du coup ?
On n’est pas obligé de faire des User Stories pour structurer le backlog !
On peut utiliser d’autres formalismes. Peut-être que le contexte ne se prête pas ou peu aux User Stories.
Les critères d’acceptation définissent ce qui est attendu
Un élément n’était pas dans les critères d’acceptation, car nous n’avions pas de recul, mais au final c’est important pour le/les clients. Du coup ça donne une nouvelle User Story pour un petit ajout qui aurait clairement fait partie de l’User Story initiale si on l’avait identifié.
Le but des critères d’acceptation est également d’aligner tout le monde sur ce que l’on attend, sur ce que cela doit faire, mais aussi sur ce qui ne doit pas être géré. Si ce n’était pas dans les critères d’acceptation, alors ce n’est pas un bug. C’est une évolution.
Les User Stories ne dispensent pas de la nécessité d’une documentation du produit
La gestion des tests automatisés : la plupart des outils de gestion des tests mettent en avant le fait de lier les “requirements” avec les “tests”. Mais comme le fonctionnel est disséminé entre toutes les User Stories qu’on a créé au fil des sprints, le lient avec les tests n’est pas évident vu qu’il n’y a pas d’US de “référence”.
Concernant la gestion du patrimoine de test, une erreur classique consiste à lier les tests aux éléments du backlog. Non, il faut lier les tests à la documentation du produit, qui évolue organiquement avec le temps.
Idéalement, c’est même l’inverse :
Quand le patrimoine de test est bien structuré, c’est ce dernier qui sert de documentation du produit.
L’agilité ne vous dispense pas de documentation.
Les User Stories ne font pas partie de Scrum
Finalement je ne sais pas si je suis à côté de la plaque à cause d’un élément d’incompréhension. Ces problématiques sont-elles couvertes par Scrum ?
Scrum ne couvre évidemment pas tous les détails. C’est un cadre de travail léger, et il faut combler énormément de trous.
En particulier, les User Stories ne font pas partie de Scrum. C’est un outil parmi d’autres.
Le Backlog Produit est éphémère et ne répond pas aux problématiques de documentation
Ces questions sont orientées par rapport à ma situation actuelle, mais je me suis posé exactement les mêmes questions lors de mes précédentes expériences agiles. Mise à jour tickets versus création de tickets éphémères à chaque fois qu’il faut “faire quelque chose”.
Il faut partir du principe que le backlog produit est éphémère.
On construit et on maintient une documentation du produit si elle est pertinente.
Dans la mesure du possible, on essaie d’utiliser le patrimoine de test en guide de documentation plutôt que d’écrire et maintenir un doc spécifique à cet effet.
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
Et pensez à souscrire à ma newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact.
À bientôt 😊
