Catégories de story

Tout est story dans le backlog

On met tout le travail de l’équipe dans le backlog (car il s’agit d’un backlog d’équipe) et tout travail est story. Cela conduit à avoir des stories pour apprendre et des stories d’investissement.

Historique de typologie des stories

La première édition de mon livre comportait déjà une rubrique sur le type de stories. À l’époque j’étais Product Owner d'iceScrum dans lequel le type était un attribut de la story avec 3 possibilités : user story, story technique et défaut. C’était visible dans les histogrammes de vélocité générés (et ça l’est encore aujourd’hui dans le graphique de vélocité ! ).

Dans l’édition 2, j’avais ajouté un 4e type : le remboursement de dette technique, ce qui faisait un beau quadrant. J’en avais fait un article.

La notion de story technique est discutable et discutée. Dans l’édition 5, j’avais changé son nom en travail technique en donnant des avertissements sur son usage.

Dans l’édition 6, j’ai approfondi la notion de valeur ; cela m’a amené à bien distinguer la valeur d’usage pour les utilisateurs de l’apprentissage pour l’équipe. La troisième catégorie s’appelle story d’investissement.

Deux points à noter pour la story d’investissement :

  • On peut s’en passer en diluant l’investissement dans les autres stories.
  • Si on souhaite la faire apparaitre, il convient de la décrire avec une orientation utilisateur, comme les autres.

Les catégories de story dans l’édition 6

Présentation sous forme de mindmap

Les nouvelles catégories de story

Version actuelle du texte sur les catégories de story dans le chapitre Backlog de la partie Boucles. La mindmap associée est un peu plus avancée que le texte.

On met tout le travail de l’équipe dans le backlog et tout est story. Cela conduit à avoir des stories un peu spéciales, car il existe des situations où les équipes passent du temps sur des travaux qui ne sont pas toujours orientés directement vers les clients et utilisateurs.

Ces travaux le sont indirectement, car la finalité de tout travail, et donc de toute story, est la valeur pour les utilisateurs.

Cette classification sert d’abord à ne pas oublier de travail dans le backlog. Elle est utile pour la définition de fini.

Il convient de décrire toutes les stories avec une orientation utilisateur, afin que le Product Owner et les parties prenantes comprennent leur intérêt.

Story à valeur utilisateur directe

Il s’agit d’une story — courante — pour un utilisateur et qui lui apportera de la valeur quand elle sera mise en service.

Exemple : Pour le site de rencontres d’animaux, « Ajouter une photo de son chien ».

Dans cette catégorie, il peut y avoir des stories de nature différente, par exemple réaliser une documentation.

Exemple : La réalisation par l’équipe d’une séquence vidéo montrant aux utilisateurs comment ajouter une photo de leur animal.

On trouve aussi la correction de bug, qui rétablit de la valeur perdue. Un bug enlève de la valeur au produit : la story sur laquelle il porte n’a plus toute celle promise. C’est sa correction qui va rétablir la valeur.

La notion de bug est assez subtile avec Scrum. Il ne faudrait pas penser qu’on stocke tous les bugs dans le backlog. D’abord, on s’efforce de détecter et corriger les erreurs introduites le plus vite possible, pendant le sprint. Et donc cela ne passe pas par le backlog. N’est pas considéré non plus comme un bug l’ajout d’une nouvelle condition d’acceptation : c’est une nouvelle story.

Les bugs dont il est question ici, ceux qui entrent dans le backlog, correspondent à des situations où on se rend compte qu’une story, déclarée finie dans un sprint précédent, présente une imperfection qui nuit à son usage. En principe, pour une équipe maîtrisant les pratiques d’ingénierie, il ne s’agit que de bugs mineurs.

Exemple de correction de bug : ajouter un retour à la ligne automatique sur le texte de la légende de la photo de l’animal, qui déborde sur la colonne d’à côté.

Toutes ces stories sont facilement décrites avec une orientation utilisateur.

Story pour apprendre

Le résultat du sprint permet d’apprendre. L’équipe apprend en finissant des stories d’ajout de valeur (qui seront mises en service ultérieurement). Elle apprend aussi avec des stories qui n’ont pas vocation à être mises en service en l’état, mais qui permettent de prendre des décisions pour une story qui sera finalement mise en service.

Exemple : L’équipe souhaite étudier une solution de stockage pour les photos et vidéos d’animaux. Le résultat de ce travail servira à la story Ajouter une photo ou une vidéo.

C’est une technique de réduction de risque (appelée spike) ; diminuer le risque, c’est apprendre.

Je recommande de décrire ces stories avec une orientation utilisateur, même si cela demande un peu d’effort de la part de l’équipe.

Dans cette catégorie, on trouve aussi des stories pour apprendre sur le fonctionnel ou l’ergonomie.

Exemple : L’équipe développe le formulaire d’inscription à l’adoption avec une ergonomie basique pour l’enrichir ensuite de ce qu’on aura appris avec le feedback auprès d’un focus groupe.

Le test A/B qui consiste à déployer deux alternatives est une forme de story pour apprendre.

Je mets aussi dans cette catégorie la story de découverte.

Story d’investissement

Il s’agit de travaux techniques ou organisationnels importants dont la valeur est indirecte pour les utilisateurs.

Dans une story, il y a toujours des travaux techniques (conception, code) et c’est très bien ainsi. Il s’agit ici de travaux qui ne proviennent pas d’une story et qui sont significatifs, au point de souhaiter en faire une story à part. S’ils ne sont pas significatifs, on préférera répartir le travail sur des stories d’ajout de valeur directe.

Faire apparaître le travail technique dans le backlog se justifie pour des travaux visant à améliorer la qualité ou la façon dont l’équipe développe : infrastructure, logistique, nouvel outil, formation, etc.

Décrire ces stories avec une orientation utilisateur est souhaitable pour montrer leur intérêt ; cela demande parfois beaucoup d’efforts de la part de l’équipe.

Exemple : Un changement de composant de recherche sera présenté avec les bénéfices en terme de temps de réponse. Un nouvel outil dans la chaine de production sera présenté avec les gains attendus pour déployer.

Le remboursement de dette technique est un investissement. La dette technique est le cauchemar du développement de logiciel. Tout le monde en a, mais peu en sont vraiment conscients. Elle ne se voit pas de l’extérieur de l’équipe ; les développeurs, s’ils s’en aperçoivent, ont du mal à la faire comprendre aux parties prenantes et même au Product Owner.

La dette technique peut être volontaire, dans le cas où est privilégié le feedback rapide avec une story pour apprendre. On ajoute alors une entrée dans le backlog pour ne pas oublier de reprendre la partie volontairement moins finie. Avec Scrum, on cherche d’abord à l’éviter. Mais, s’il y en a, il est préférable de la rembourser le plus tôt possible, car les intérêts s’accumulent, comme pour une dette financière. Une fois le plus gros de la dette remboursée, il faut prendre les dispositions pour ne plus en réintroduire, c’est l’objectif de la définition de fini.

Exemple de remboursement de dette technique : remanier le code du composant de téléchargement qui n’est pas maintenable.

L’identification de la dette technique, en vue de la limiter, va dans le sens du développement durable et c’est dans ce sens que cela sera présenté au Product Owner et aux parties prenantes.

Travaux techniques et remboursement de dette ne sont pas toujours visibles dans le backlog. L’équipe peut décider de les inclure dans une story, considérant que c’est sa responsabilité de faire ces investissements sans les faire apparaitre.


Un commentaire sur le texte ou le schéma ? Écrivez-moi par email ou par Twitter.

Voir aussi