🗞 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:

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:

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:

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:

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:

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:

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é

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:

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

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:

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:

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:

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:

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

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:

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

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:

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:

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?

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

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:

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):

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.

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:

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:

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.