🗞 Bien écrire ses User Stories

Qu’est-ce qu’une User Story?

Une user story est une fonctionnalité qui a une valeur pour son utilisateur. Elles sont composées de trois aspects:

• La description qui est notamment utilisé pour se rappeler de quoi il s'agit
• Le détail des échanges sur l’US ou du détail complémentaire permettant de bien comprendre l'attendu
• Les tests d’acceptation qui doivent permettre de déterminer si l’US est complète et qui permettent de documenter le détail (notamment tous les cas non nominaux)

Exemple (STORY 1): « Un utilisateur peu uploader son SIRET sur le site web »

Etant donné que les US représentent des fonctionnalités, les exemples suivants ne sont pas des US:

• Le système devra se connecter à une base de données
• Mettre en place un micro-service

Dans les deux cas, l’utilisateur final du produit n’a pas d’intérêt dans ce qui est décrit et donc cela n’a pas de valeur pour lui.

L’intérêt de rédiger des User stories plutôt que des exigences ou des spécifications est multiple:

• Il permet de favoriser la communication verbale plutôt qu’écrite car il déclenche le débat
• Le contenu des US étant légèrement, en particulier au début, il oblige les développeurs et les autres parties prenantes à poser des questions, à proposer des modes de fonctionnement ce qui va améliorer la créativité collective autour de cette story
• Les US sont compréhensibles par tous les membres de l'équipe
• Etant écrite par la Customers Team, les US ne contiennent aucun jargon technique ce qui les rend compréhensible par le collectif
• Elles font la bonne taille pour les planning
• Les US étant indépendantes et de petites pièces, cela permet de les réordonner facilement et de changer ainsi l’ordre dans lequel la valeur est délivrée ce qui rend le planning flexible
• De la même manière, il est possible jusqu’au dernier moment d’ajouter des US ou d’en enlever ce qui là aussi donne de la flexibilité à la gestion du produit
• Elles marchent pour le développement itératif

Un process itératif est celui qui permet de voir le progrès par vague successives d’affinement.

1. Une première version du système dans son ensemble sera délivré par l’équipe de développement tout en sachant que c’est incomplet
2. Puis chaque itération permettra d’enrichir la précédente
• Elles encouragent l’écriture du détail au dernier moment, qui est aussi le moment où la maturité est la plus forte
• Elles permettent également de gérer ce qui n’est pas nécessaire immédiatement en créant de grosse User Stories peu détaillée. Elle sera quand même créé car elle n’est pas importante de suite mais parcequ’elle le sera probablement plus tard. Le jour où approche son implémentation il sera alors possible de la diviser en plusieurs US
• Dans une première version de backlog, il y a souvent beaucoup d’épics mais assez peu d’US (uniquement les premières). Les Epics seront découpées au dernier moment ce qui permet d’y ajouter le détail le plus tard possible

Ecrire des User Stories

L’écriture des User Stories est primordiale car elle va entrainer la bonne capacité à prioriser et à délivrer de la valeur. Une bonne User Story est:

• Indépendante
• Négociable
• Porteuse de valeur pour l’utilisateur du produit
• Estimable
• Petite
• Testable

Independant

Il faut autant que possible éviter les dépendances entre les stories. Ces dépendances entrainent problèmes de priorisation et de planning.

Par exemple, si l’utilisateur sélectionne une US très prioritaire mais qui est dépendante d’une US non prioritaire, tout notion de priorité est alors caduc

Elles rendent également les estimations plus complexes. Par exemple, si pour une US qui serait "Un utilisateur peu payer les éléments de son panier avec une carte de crédit » on écrit 3 US:

• Un HO peut payer pour un package en VISA
• Un HO peut payer pour un package en MasterCard
• Un HO peut payer pour un package en American Express

Si les développeurs estiment à 3j le support du premier type de carte et ensuite à une journée les deux autres. Avec ces stories fortement couplées on ne sait pas ce qui est présent dans les estimations (car en fait elles inclus le fait de payer en CB de manière générique et ensuite la déclinaison par type de carte)

Dans ce genre de cas il y a deux tactiques possibles:

• Regrouper les trois US dans une seule plus grosse mais indépendante

Cette tactique fonctionne à condition que l’US regroupée ne soit pas trop grosse

• Trouver un moyen différent de diviser les US

Dans notre cas, l’US regroupée pourrait être redécoupée selon une autre façon de voir les choses:

1. Un HO peut payer un package en carte de crédit (n’importe quel type)
2. Un HO peut payer un package avec trois type de carte: VISA, MasterCard, AMEX

Dans cet exemple, il y a toujours une dépendance entre la seconde US et la première mais au moins on sait quelle US prote quelle complexité

Négociables

Les US sont négociables. Ce ne sont pas des contrats avec une liste d’exigence envers l’équipe de développement. L’ensemble des discussions autour de l’US peut-être associé afin d’y avoir un souvenir des discussions et des choix réalisés. Mais l’US en elle même doit rester légère. Elles ne contiennent pas tout le détail mais peuvent contenir l’historique de discussion ayant amené à certains choix. Cela d’une part pour susciter le débat mais également pour ne pas brider la créativité.

Une story trop légère comme celle indiquée ci-dessous pose trop de questions sur sa réalisation: quels type de carte doivent être acceptés? De ce fait s’il y a une estimation, celle-ci ne sera pas précise par manque de détail sur l'US

Le challenge réside dans l’apprentissage du niveau de détail approprié à inclure dans une US. Sur notre exemple, nous pourrions par exemple ajouter:

Cette US est simple et contient aussi bien la fonctionnalité que les détails nécessaires à sa réalisation. Si en plus dans l’historique de conversation autour de l’US on peu retrouver comment les choix ont été fait, cela aidera la compréhension du développeur

Une autre manière d’écrire l’US:

Dans son détail, cette US contient réalité 3 fonctionnalités: celle du paiement, celle de l’affichage du type de carte, celle de la collecte d’information sur la carte. La lecture d’une US de ce type est très difficile et surtout elle va introduire un biais: le titre semble simple mais il y a de la complexité dans la description. Par ailleurs et de pas la manière dont les notes sont écrites, l’US ne semble pas soumise à discussion.

Une bonne pratique réside dans:

• L'écriture dans un premier temps du titre uniquement au bon niveau de détail
• Poser des questions autour de cette US (qui sont consignés dans la conversation liée à l’US)
• Toutes les réponses à ces questions donneront le détail et les tests d'acceptation

Porteuse de valeur pour l'utilisateur

L’idéal serait de pouvoir évaluer la valeur utilisateur de chacun des User Story. Malheureusement ce n’est pas applicable. Un projet contient toujours des US qui n’ont pas de valeur directe pour l’utilisateur du produit.

Par exemple une US qui serait: « Toutes les erreurs cachées et les logs seront stockées dans DataDog » n’a aucune intérêt pour un utilisateur qui se moque de savoir où sont stockées les erreurs. La même pourrait s’écrire en disant: « Toutes les erreurs sont présentées.à l’utilisateur de manière consistante »

Elles représentent le même travail mais dans le second cas on comprend pourquoi elle doit être faite et elle n’enferme pas la réalisation de l’US dans un choix technologique arbitraire

Estimables

Il est primordiale que les développeurs soient en mesure d’estimer les User Stories (cf. Priorisation). Il y a classiquement trois raisons pour lesquelles les US ne sont pas estimables:

• Manque de connaissance dans le domaine par les développeurs

Si les développeurs ne comprennent pas l’US ils peuvent alors en discuter avec le PO afin d’obtenir la compréhension nécessaire à l’évaluation du niveau de complexité

• Manque de connaissance technique des développeurs

Si parceque l’équipe est nouvelle, que le framework maison n’est pas connu ou autre les développeurs ne sont pas en mesure de déterminer un niveau de complexité il est alors possible d’agir en créant des Spike (issu de l’Extrême Programming) ou des POCs qui vont leur permettre d’expérimenter et donc d’apprendre la technologie sous-jacente. Les Spike sont toujours limités dans le temps (pour ne pas dériver vers un développement de fonctionnalité). Dans ce cas la story est découpé en deux: le spike avec une TimeBox et ensuite l’US a réaliser

• L’US est trop grosse

Dans ce cas le nombre de question, le niveau d’incertitude, le niveau de risque technique & co est trop élevé pour avoir une estimation précise. Dans ce cas avant d’estimer il faut diviser les User Stories en d’autres US plus petites et étant estimables.

Petites

Trouver la bonne taille d’US est importante car elle permettra notamment une planification correcte.

Par exemple, dans un système de réservation de voyages, « Un utilisateur peu planifier des vacances » est une Epic. C’est une fonctionnalité importante pour le système de réservation mais il y a trop d’autres tâches embarquées dans cette simple story pour être utilisée telle quelle. L’épic devra donc être divisée en plusieurs User Stories.

La détermination de la bonne taille est basée sur trois facteurs: l’équipe, sa capacité et les technologies utilisées

Diviser les Epics/Stories

Les Epics appartiennent généralement à deux catégories:

• Les stories composée
• Les stories complexes

Une storie composée est un agrégat de plusieurs stores plus petit.

Par exemple, sur un site de recherche d’emploie, nous pourrions voir l’US « Un utilisateur peu poster son CV » . Lors du planning initial, cette US peut-être de la bonne taille. Mais en discutant avec les développeurs, plusieurs autres fonctionnalités vont apparaitre:

• Le CV peu contenir les diplômes, les jobs précédents, le salaire, les publications, les compétences, les loisirs
• Les utilisateurs peuvent désactiver les CV
• Les utilisateurs peuvent avoir plusieurs CV
• Les utilisateurs peuvent éditer leur CV
• Les utilisateurs peuvent supprimer leur CV

En fonction de la durée de chacune des fonctionnalités, elles peuvent devenir des US.

Dans ce cas nous sommes face à une épic qui doit être divisée en plusieurs US comme par exemple:

• Un utilisateur peu créer un CV incluant le cursus scolaire, les jobs précédents, le salaire, les publications, les compétences, les loisirs
• Un utilisateur peu éditer son CV
• Un, utilisateur peu supprimer un CV
• Un utilisateur peu avoir plusieurs CV
• Un utilisateur peu activer et désactiver des CV

Le découpage de la story composée se fait ici par le prisme de l’ajout/édition/suppression mais il est aussi possible de découper selon les frontières de l'Epic

• Un utilisateur peu ajouter/éditer les informations de cursus scolaire
• Un utilisateur peu ajouter/éditer les informations d’historique de jobs
• Un utilisateur peu ajouter/éditer les informations de salaire
• Un utilisateur peu ajouter/éditer les informations de publications
• Un utilisateur peu ajouter/éditer les informations de compétences
• Un utilisateur peu ajouter/éditer les informations de loisirs

Contrairement à l’Epic composée, l’Epic complexe est une User Story qui ne peut pas facilement est décomposée en d’autres User Stories. Si la complexité provient d’une part d’incertitude, il faut alors découper l’Epic en une première US d’investigation et une seconde de réalisation. Dans le cas du paiement par exemple, si l’US est « Un propriétaire peu payer la pose avec sa CB » et qu’aucun développeur de l’équipe n’a travaillé sur uyn système de paiement, il y aura un découpage en deux partie:

• Investigation du traitement des cartes bancaires sur le web (Timebox)
• L’utilisateur peut payer avec sa carte de crédit

L’avantage d’ajouter des spike (phase d’investigation) est de permettre au PO de prioriser les phases d’investigation avant les phases de réalisation. Ce qui est préférable plutôt que de prioriser la réalisation d’un fonctionnalité sur la base d’une estimation qui est fausse.

NOTE: il est en général préférable de mettre le Spike dans un sprint différent de la réalisation afin de ne pas créer de dépendances

Testable

Les US doivent être écrites de manière a être testable. Des tests passés avec succès permettant de prouvé que l’US a été correctement développée. Sinon, comment peut-on vérifier que le travail a été correctement accompli? Habituellement les US non testable sont celles qui ne sont pas fonctionnelles comme par exemple:

• L’utilisateur doit trouver le logiciel facile à utiliser
• L’écran doit s’afficher rapidement

Dans les deux cas le résultat attendant est subjectif (comment on mesure « facile à utiliser » ou « rapidement » ?) ce qui rend l’objectif non clair et les tests impossibles à réaliser. Une meilleure façon d’écrire cette US sera de dire:

• Les écrans apparaissent en moins de 2s pour 95% des utilisateurs

RAPPEL

En Agile l’une des meilleure façon de faire pour la gestion de tests est d’automatiser le plus de tests possibles parmis les tests d’acceptation. Cela permet notamment de gérer la régression et de ne pas surcharger de travail les PO avec les tests/

Cf. TDD

Quels sont les détails?

Ecrire une US telle que « Un utilisateur peu uploads son KBIS sur le site web » lève un certain nombre d’interrogations. Où sont les détails? Que faire de tout ce qui est périphérique?

• Quelles sont les informations associés que l’utilisateur doit indiquer? Date d’expiration du KBIS? SIRET? SIREN? Type d’entreprise?
• Est-ce que l’utilisateur doit être déjà membre (et donc authentifié)
• Que doit-on enregistrer?

La branche package du site de Quotatis pourrait très bien être décrit en deux US

• Un utilisateur peut chercher un artisan pour la réalisation d’une pose package
• Un pro peut postuler à la réalisation de packages

Ces deux US sont clairement trop grosse pour être vraiment utile. Le sujet de la taille des US sera traité plus tard mais en point de démarrage on peut considérer que la taille d’une US (son développement + l’écriture et l’éxécution des tests) doit être comprise entre une demi-journée et la taille du sprint (2 semaines). Lorsque les US sont plus grande on parle plutôt d'Epic. Les Epics peuvent être divisée en deux ou plus US de taille plus petite. Par exemple l’US « Un utilisateur peu chercher un artisans pour la réalisation d’une pose » peut être divisée en:

• Un utilisateur peut chercher pose de package par zone géographique, prix, niveau de qualification des artisans
• Un utilisateur peut voir tous les artisans susceptible de réaliser ses travaux
• Un utilisateur peut voir tout le détail de l’entreprise ayant pris son package

On arrête de diviser les US a partir du moment où elles sont dans le fourchette de taille indiquée ci-avant et permettant de couvrir tout le détail nécessaire.

Sur l’US "Un utilisateur peut voir tout le détail de l’entreprise ayant pris son package », on peu associer à l’US du détail tel que: « Afficher la description, le prix, les travaux réalisés, le niveau de qualification » mais ces informations ne sont pas contractuelles. Ce qui est contractuel réside dans les tests d’acceptation./

Toutes les attentes des utilisateurs pour une User Story donnée doivent apparaitre dans les tests d’acceptation et peuvent être par exemple (dans le cas de la STORY 1):

• Essayer avec un champs « Document » vide
• Essayer avec un document qui n’est pas au bon format
• Essayer avec un document qui n’est pas un SIRET
• Essayer avec un SIRET qui n’est pas valide

Outre la validation des US, l’objectif des tests d’acceptation est également de détailler le niveau attendu sur l’US

A quoi peut ressembler le process d’écriture des US ?

Contrairement à ce qu’il se passe dans un cycle en V, en Agile l’utilisateur est attendu pour être impliqué tout au long du projet. Le process d’écriture des User Stories est le premier moment où les utilisateurs sont impliqués dans le projet. Il est en général utile de créer une équipe utilisateur qui regroupe dDifférente typologie d’utilisateurs (Pro indépendant, Entreprise de BTP, etc.)

Souvent on commence par déterminer des typologies d’utilisateurs que l’on va personnaliser sur des personnes fictives: les personae

Les US sont généralement décrites par l’équipe utilisateurs pour deux raisons principales:

1- Parceque ce sont les utilisateurs qui sont le plus à même de donner les priorités

2- Les utilisateurs étant ceux qui utiliseront le produit, ils ont la meilleure position pour en donner le comportement

Généralement avant le démarrage d’un projet ou d’une release d’un projet, des « Writing workshop » sont organisés avec l’équipe utilisateur afin que tout le monde puisse brainstormer sur les US qui seront attendues. Dans un premier temps les US issues de ces ateliers seront plutôt de grande taille et couvriront l’ensemble du périmètre du produit.

Avec ce premier set d’US l’équipe de développement fait alors une estimation de chacune d’entre elle: cela permettra d’avoir un backlog de release estimé. Les PO vont ensuite ordonner ces US dans des piles avec une pile par Sprint. Le contenu de chacun des sprints sera basé sur la capacité de production estimée de l’équipe (soit issue des mesures réalisées dans des release précédente), soit estimée.

• Les US les plus prioritaires sont mises dans les premières itérations

Autant de piles que d’itération sont alors créées jusqu’a la fin de la release ce qui va alors permettre de connaitre le périmètre fonctionnelle souhaité pour la fin de release.

Au fur et à mesure de l’avancement de la release, la vélocité va s’affiner sur la base des réalisations réelles permettant de mettre à jour le plan de Release et le périmètre à couvrir. Cela implique qu’en fonction des ajustement, chaque pile d’US devra s’ajuster par l’ajout ou le retrait de User Stories.

Il est inévitable qu’au court de la release certaines US apparaissent, que d’autres soient modifiées ou encore que l’estimation se révèlent fausse. Cela parce que tout le contexte n’est pas forcément parfaitement connu. La conséquence sera de pousser les US les moins prioritaires de la release vers la sortie. Elles ne seront donc pas réalisées.

Planifier les Release et les itérations (Sprint)

Une release est un ensemble de plusieurs itérations (sprints). La définition d’une release revient à choisir un ensemble de User Stories à inclure dans une fenêtre de temps fixe. La team d’utilisateur ET les développeurs sont impliqués dans sa préparation.

Pour planifier une Release, l’équipe utilisateur commence par:

• L’utilité de la fonctionnalité pour base large d'utilisateurs
• L’utilité de la fonctionnalité pour un petit nombre d’utilisateurs clés
• La cohérence de la fonctionnalité vs les autres US embarqués dans la release

Les développeurs vont intervenir dans la priorité de ces US pour des cas qui peuvent être: le risque technique pris sur une US donnée ou encore le fait qu’un US soit complémentaire à une autre. L’équipe d’utilisateurs va écouter les recommandations des développeurs et prendra sa décision de telle sorte à maximiser la valeur pour l’organisation (qui est un équilibre entre le risque pris et la valeur pour l’utilisateur)

Il n’est pas possible de prioriser un backlog sans prendre en considération le coût des US. Le coût est représenté par l’estimation donnée par les développeurs.

Le Release Plan est alors réalisé en affectant chacune des US à chacun des sprints backlog qui compose la release. Dans JIRA cela se fait en créant tous les sprints d’une release et en y affectant les US selon la vélocité attendue.

Si l’on a un backlog tel que:

Et si la vélocité de l’équipe est de 13pt cela implique que chaque sprint ne peut dépasser 13pt ce qui donnera un plan de Release tel que:

Les tests d'acceptation

Les tests d’acceptation représentent le process permettant de vérifier que ce qui est développé correspond au attentes des utilisateurs. Quand un sprint démarre, les développeurs commencent le développement et les PO commencent la rédaction des cas de test.

Les tests doivent être écrits le plus tôt possible dans le sprint (idéalement avant le démarrage du sprint). Le fait d’écrire ces tests avant le démarrage de l’itération est très facilitant pour la réussite du sprint car ils permettent aux développeurs de mieux comprendre les attentes.

Par exemple sur un User Story qui serait « Un utilisateur peu payer les éléments de son panier avec une carte de crédit », les tests d’acceptation pourraient être:

• Tester avec VISA, MasterCadrd et American Express: OK
• Tester avec Diner’s Club: KO
• Tester avec une carte de débit VISA; OK
• Tester avec un bon, un mauvais et sans cryptogramme
• Tester avec une carte expirée
• Tester avec différents montant (incluant des montant dépassant les plafonds des cartes de crédit)

Ces différents tests informeront les développeurs sur les cartes qui peuvent fonctionner mais les obligeront également à prévoir les cas d’échec sur les cartes expirées, les cartes non acceptées, etc.