Story Agile #7 Rédaction d’une user story

Dans Story Agile , 30 octobre, 2020

Ou comment aligner le fonctionnel et la technique sur l’attendu

Rédiger une story, c’est simple à expliquer, mais plus compliqué dans la réalité ! Juliette va être confrontée à l’exercice de la rédaction et du découpage d’une story.

Nous allons voir les problématiques qu’elle va rencontrer et les astuces que pourra lui donner Basile.

Juliette a suivi la formation Product Owner, organisée par Celencia, ce qui lui a permis d’appréhender les concepts et de s’exercer sur des cas pratiques. La définition du backlog et la rédaction des stories étaient simples et évidentes. Place maintenant à la rédaction des premières stories du site de vente en ligne de Ventout.

Nous allons voir que Juliette va rencontrer les mêmes difficultés que tout le monde au démarrage :

  • Quelle est la finesse d’une story ?
  • Peut-on utiliser cette formalisation auprès des utilisateurs ou des parties prenantes ?
  • Comment être sûr de ne pas oublier des stories tests ou tests d’acceptations ?

A ce stade, Juliette n’est pas perdue ou paniquée, bien au contraire ; mais elle a besoin d’être confortée dans son approche et de bénéficier de retours d’expériences. C’est là que Basile entre en scène !

Tout d’abord, Basile lui propose une démarche en 2 temps, qu’elle pourra bien sûr adapter avec son expérience :

  1. Réaliser un atelier de travail métier, par fonctionnalité sélectionnée dans le backlog. L’objectif sera de la découper en story, le plus finement possible, avec le formalisme « En tant que… je souhaite … afin de … ». Ainsi, le langage est commun et transparent. Si possible identifier des tests ou cas métiers standards et aux limites, sans rentrer dans le détail. Pour les fonctionnalités relatives au front, il lui propose d’être accompagnée par un UX pour avoir une approche design thinking.
  2. Réaliser un (ou plusieurs) atelier(s) de co-conception, limité à 1h, avec un ou deux développeur(s) choisi(s) de manière aléatoire. L’objectif est d’affiner le découpage et de co-rédiger les stories tests. Cette étape fera gagner du temps lors du sprint planning, en identifiant tout obstacle ou imprécision.

Juliette est surprise par la deuxième étape car elle pensait rédiger les stories uniquement avec des interlocuteurs métiers ; ni que les développeurs auraient à appliquer ce qui avait été formalisé. Cependant, elle comprend l’approche de co-construction et d’échange permanent avec l’équipe de développement.

Round 1 : l’atelier métier

Juliette présente aux participants sa vision sur la fonctionnalité de paramétrage d’un produit, sous forme de mind mapping. Chaque participant l’enrichit pour avoir une cartographie complète de la fonctionnalité.

Ensuite, l’atelier s’oriente vers la rédaction des stories de chaque item identifié. Le format de story est bien accueilli par les participants, dont un prononcera la phrase culte : « je comprends enfin ce que vous voulez faire ».

Néanmoins, Basile donnera quelques astuces pour bien cadrer la rédaction :

  • Si vous ne trouvez pas d’utilisateur ou de finalité à la story, il n’y a peut-être pas de réel besoin. Je vous invite à les mettre de côté pour l’instant.

En tant que paramétreur, je souhaite définir la couleur du produit afin de… ?

  • Si dans la rédaction de l’action attendue, vous commencez à mettre des « et », c’est qu’il y a probablement plusieurs stories.

En tant que paramétreur, je souhaite définir le nom du produit et le prix et ses dimensions afin de le proposer au client.

Round 2 : la co-conception

Juliette présente à un ou deux développeur(s) les stories prioritaires, identifiées lors de l’atelier métier. Ils affinent les stories pour la bonne compréhension de tous et envisager la solution. Ensuite, pour chaque story, les tests d’acception sont co-écrits toujours dans une perspective de transparence et surtout d’exhaustivité.

A la fin de la séance, Basile demande une première estimation sur la base de la suite de Fibonacci. Au-delà de connaître l’effort de réalisation, cela permet d’avoir une idée de la taille des stories. Cette estimation sera bien évidemment revue et validée lors du sprint planning.

Il s’avère que toutes sont comprises entre 3 et 8 points, sauf une qui est à 20 : le paiement par CB.

En tant que client je souhaite pouvoir régler mon panier via carte bancaire afin de raccourcir le délai de réception des produits.

Il propose d’essayer de la redécouper car sa taille pourrait refléter un manque de maturité sur le sujet. Son intuition était la bonne car elle sera redécoupée en deux stories, dont une non mature pour entrer dans le prochain sprint :

  • Cas du client avec règlement par Mastercard ou autre type de CB classique
  • Cas du client avec règlement via Paypal (non mature et non prioritaire)

Juliette poursuivra les ateliers métiers et de co-conception tout au long du sprint afin d’être prête pour le prochain sprint planning.