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

Scrum Storypoints Fibonacci

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