đź—ž Bien Ă©crire ses User Stories

đź—ž 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 fonctionnalisé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.
    • 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

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

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

Untitled

Title

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:

Untitled

Title

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:

Untitled

Title

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:

Untitled

StoryStory Points
Story A
3
Story B
5
Story C
5
Story D
3
Story E
1
Story F
8
Story G
5
Story H
5
Story I
5
Story J
2

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:

Untitled

IterationStoriesPt
Itération 1
A, B, C
13
Itération 2
D, E, F
12
Itération 3
G, H, J
12
Itération 4
I
5

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.