Histoire d'utilisateur

Toutes les fonctionnalités sont décrites sous forme de User Stories

As a {role} i want {function} because {benefit}

Critères d’acceptation :

ac 1
ac 2
ac 3

La User Story décrit l’état et le comportement de l’incrément après la mise en œuvre des exigences et ne décrit pas de solution (technique) (à l’exception des conditions techniques).

Critères INVEST

Independent– indépendant. Les stories doivent pouvoir être implémentées indépendamment les unes des autres.

Negotiable– négociable. Des modifications peuvent être apportées à l’histoire (en concertation).

Valuable– utile. La mise en œuvre de l’histoire augmente la valeur d’usage du produit pour le client final.

Estimable– quantifiable. Le coût de la mise en œuvre doit pouvoir être évalué. (Toutes les informations nécessaires doivent être disponibles à cet effet)

Small– petit. Le coût de la mise en œuvre doit être gérable. Réalisable en l’espace d’un sprint.

Testable– vérifiable. La réussite de la mise en œuvre de l’histoire devrait pouvoir être vérifiée à l’aide de critères. Critères d’acceptation raisonnablement mesurables

Exemple d'histoire

Onboarding, login et gestion des utilisateurs

RGPD

En tant qu’utilisateur, je souhaite m’inscrire dans l’application afin de pouvoir réserver des machines et utiliser le service.

Critères d’acceptation :

lors de l’affichage de l’écran de connexion, il y a une option pour s’inscrire en tant que nouvel utilisateur
si l’utilisateur appuie sur le bouton d’enregistrement, le processus d’enregistrement démarre
L’utilisateur suivra un processus d’intégration étape par étape, il ne pourra passer à l’étape suivante que s’il remplit toutes les exigences de l’étape actuelle.
- Étape 1 – L’utilisateur doit saisir son adresse e-mail et un mot de passe (2 fois pour la validation) pour l’enregistrement initial.
  - Exception e-mail déjà existant -> show message to user
  - Exception Les règles relatives au mot de passe ne sont pas respectées -> show message to user
- Étape 2 – après cela, un e-mail est envoyé à l’utilisateur avec un code à 4 chiffres pour la validation de l’e-mail (le code de confirmation doit faire partie du sujet de l’e-mail). L’utilisateur peut saisir le code à 4 chiffres pour valider son e-mail. il y a aussi une option pour renvoyer l’email
  - Exception Digit Code is wrong -> show message to user
- Étape 3 – L’utilisateur doit saisir ses données d’adresse (rue, numéro, code postal, ville). Tous les champs sont obligatoires.
  - Exception champs obligatoires -> l’étape suivante n’est possible que si tous les champs obligatoires sont remplis
- Étape 4 – L’utilisateur doit télécharger une photo de son document d’identité (carte d’identité, permis de conduire ou passeport). Après avoir pris une photo, l’utilisateur a la possibilité de la retirer ou de la confirmer. Show upload progress after taking the photo
  - Exception upload failed -> show message, user can initialize reupload
une fois que l’utilisateur a parcouru toutes les étapes, un écran d’aperçu s’affiche et il peut enfin confirmer
sur l’écran de confirmation, il y a des cases à cocher pour les consentements en matière de politique de données et d’informations sur les produits
si un utilisateur s’absente après la deuxième étape de l’enregistrement, le questionnaire commencera toujours directement après la connexion
la mise en page et les interactions doivent être mises en œuvre conformément au design et au modèle d’utilisation et d’interaction commun de la plate-forme mobile correspondante

Conseils pour la rédaction de User Story

Garde l’histoire aussi simple que possible
Décrire clairement dans l’histoire le déroulement attendu et les états définis
Ne te focalise pas uniquement sur le “happy path” et essaie de définir les exceptions.
Complète l’histoire avec toutes les informations directement liées à la mise en œuvre.
Une User Story n’est pas un contrat fixe – garde la communication ouverte avec l’équipe pour définir la meilleure façon de la mettre en œuvre avec elle .

Story Estimation chez Elasticbrains

Évaluation de l’USER STORY par

Complexité
Risque
Dépendances

Estimation dans le Planning Poker

Chaque développeur* apprécie la User Story pour elle-même
Tout le monde montre son estimation en même temps
Les développeurs* ayant l’estimation la plus élevée et la plus basse expliquent leur point de vue
L’équipe discute et se met d’accord sur une valeur
Le/la développeur/se avec l’estimation la plus élevée peut insister sur l’estimation en cas de doute et c’est alors celle-ci qui est prise en compte.
le cas échéant le Product Owner* peut modifier la Story pour réduire la complexité, le risque ou les dépendances

Storypoints chez Elasticbrains -> Fibonacci sans 2

si l’estimation est supérieure à 13 points d’histoire, l’histoire doit être fractionnée

Plus de sujets dans notre section Agile :

Cookie	Durée	Description
cookielawinfo-checkbox-analytics		Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour enregistrer le consentement de l'utilisateur pour les cookies dans la catégorie "Analytics".
cookielawinfo-checkbox-functional		Le cookie est défini par le consentement au cookie GDPR pour enregistrer le consentement de l'utilisateur pour les cookies de la catégorie "Fonctionnel".
cookielawinfo-checkbox-necessary		Ce cookie est défini par le plugin GDPR Cookie Consent. Les cookies sont utilisés pour stocker le consentement de l'utilisateur pour les cookies dans la catégorie "Nécessaire".
cookielawinfo-checkbox-others		Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour enregistrer le consentement de l'utilisateur pour les cookies dans la catégorie "Autres.
cookielawinfo-checkbox-performance		Ce cookie est défini par le plugin GDPR Cookie Consent. Le cookie est utilisé pour enregistrer le consentement de l'utilisateur pour les cookies dans la catégorie "Performance".
viewed_cookie_policy		Le cookie est défini par le plugin GDPR Cookie Consent et est utilisé pour enregistrer si l'utilisateur a consenti ou non à l'utilisation de cookies. Il ne stocke pas de données personnelles.