L’un des objectifs de l’agilité est d’apporter simplement (éviter la complexité et les tâches inutiles), rapidement et périodiquement des fonctionnalités à grande valeur ajoutée aux clients.
Une User Story est l’unité de base de valeur métier produite pour un client. Il s’agit d’une description simple d’un besoin sous forme d’une histoire et c’est le fruit d’une collaboration entre les équipes métier et les équipes techniques. Il existe plusieurs tutoriels et exemples d’US, pour moi, c’est à l’équipe de définir le format qui lui convient pour mieux travailler. Dans cet article, je partage avec vous le formalisme qui a été adopté au sein d’un de mes projets.
Description d’une User Story
| ID : #123 | Type : Fonctionnel | Estimation : 3P |
| Titre : Ajout d’un produit au panier |
||
| Objectif : En tant que xxxx, je souhaite xxxx afin de xxxx |
||
| Détail : Description du parcours utilisateur et rappel du contexte Maquette statique ou lien vers une maquette dynamique Les règles métier : les messages d’erreur, type (numérique, chaine de caractère...), taille des champs… |
||
| Critères d’acceptation : Etant donné XXXX Lorsque XXXX Alors XXXX |
||
Une User Story contient 7 parties :
Identifiant :
Il s’agit de l’identifiant généré par le logiciel utilisé ou un numéro affecté manuellement à l’US. Cet identifiant est surtout utilisé par le PO et les développeurs pour identifier facilement les US.
Titre :
Description du besoin via une phrase courte.
Exemple :
Validation d’une réservation d’hôtel, ajout d’un produit au panier
Type :
Fonctionnel : pour un besoin fonctionnel
Technique : pour un besoin technique
[EVOL] : pour une modification d’une US existante. Ce tag permet de garder l’historique des évolutions.
Objectif :
Présentation de la vision utilisateur avec la formulation : En tant que [X], je veux [Y], afin de [Z].
On répond aux questions suivantes :
– Qui est le persona ou le type utilisateur
– Qu’est ce qu’il souhaite faire?
– Quelle est la valeur métier attendue?
Exemple :
En tant qu’utilisateur, je veux accéder au panier, afin de vérifier la liste des articles
Détail :
Dans cette partie, on trouve le détail du besoin : expliquer le parcours utilisateur, définir les messages d’erreur, expliquer les règles métier, expliquer les maquettes…
Critères d’acceptation:
Les critères d’acceptation sont les tests effectués pour s’assurer que le produit développé répond au besoin exprimé. Ils décrivent les actions de l’utilisateur et détaillent son besoin en se basant sur la méthode BDD (Behavior Driven Development)
Exemple :
Etant donné que [Contexte] : Etant donné que je veux me connecter
Quand [L’événement] : Quand je clique sur le bouton “Se connecter”
Alors [le résultat] : Alors la page de connexion s’ouvre
Estimation :
Il s’agit de l’estimation fournie par l’équipe de développement. Il existe plusieurs façon d’estimer le coût d’une user story : T-Shirt Sizing, suite de Fibonacci…
Si à la fin du sprint, l’US a été débutée mais non finalisée, au sprint suivant, l’estimation va correspondre au reste à faire.
Caractéristiques
Les US doivent être INVEST :
- “Independent” : chaque US doit apporter de la valeur indépendamment des autres US
- “Negociable” : une US est un support de discussion, elle peut être remise en question et négociée du moment que son implémentation n’est pas encore engagée.
- “Valuable” : elle apporte de la valeur business
- “Estimable” : elle doit être claire pour que l’équipe de développement puisse l’estimer
- “Small” : elle doit être suffisamment découpée pour être développée en un seul sprint
- “Testable” : elle doit être accompagnée de critères d’acceptation qui permettent sa validation
Priorisation
Les US à développer en priorité sont celles qui apportent le plus de valeur ajoutée. Pour cela, je me base sur le WSJF (Weighted Shortest Job First) qui est calculé en divisant “le coût du retard” par “le coût d’une US”.
Coût de retard = Valeur Business + Réduction des risques et création d’opportunité + Criticité temporelle
- Valeur Business : la valeur métier votée par les utilisateurs finaux et les décideurs stratégiques
- Réduction des risques et création d’opportunité : identifie la réduction des risques et la création d’opportunité une fois l’US développée. Par exemple une US technique n’apporte généralement pas de valeur métier, cependant elle peut offrir l’opportunité de développer de nouvelles fonctionnalités.
- Criticité temporelle : détermine si l’US est à livrer rapidement ou non. Cette valeur peut évoluer donc il ne faut pas hésiter à la réévaluer. Par exemple, une US qui décrit un service pour vendre les œufs de pâques est critique avant Pâques une fois Lundi de Pâques est passé elle devient moins critique.
La règle est de développer les US ayant la valeur WSFJ la plus élevée en priorité.
A éviter
- Un découpage Front / Back des US
- Ne pas prendre en compte les retours des équipes techniques et figer une US après sa rédaction
- Avoir des US très coûteuses cela veut dire qu’il faut les découper
- Ne pas affiner les US avec les développeurs avant le début du sprint
2 commentaires