La User Story est l'élément constitutif essentiel d'un
Classiquement une User Story est écrite sous la forme suivante:
En tant que XXX je souhaite YYY afin de ZZZ
"XXX" doit représenter la personne qui sera utilisatrice de la User Story au sein du produit fini
"YYY" représente ce que l'on cherche à faire dans l'histoire utilisateur
"ZZZ" représente l'intérêt attendu de l'histoire utilisateur
Qu'est ce qu'une User Story (dans le détail) ?
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
- 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
- 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
Un process itératif est celui qui permet de voir le progrès par vague successives d’affinement.
User story INVEST
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
- Trouver un moyen différent de diviser les US
- Un HO peut payer un package en carte de crédit (n’importe quel type)
- Un HO peut payer un package avec trois type de carte: VISA, MasterCard, AMEX
Cette tactique fonctionne à condition que l’US regroupée ne soit pas trop grosse
Dans notre cas, l’US regroupée pourrait être redécoupée selon une autre façon de voir les choses:
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
- Manque de connaissance technique des développeurs
- L’US est trop grosse
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é
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
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