Comment rédiger de bonnes histoires d’utilisateur dans Scrum

Environ 70 % des projets technologiques échouent. Pendant des décennies, on a largement cru que les projets échouaient parce qu’ils ne suivaient pas les meilleures pratiques ou parce que l’équipe manquait de toutes les compétences nécessaires. Toutefois, l’adoption des meilleures pratiques, des compétences et des compétences clés s’est améliorée au fil des décennies — alors pourquoi les projets échouent-ils encore ?

En tenant compte du fait que 70 % des projets logiciels échouent en raison de mauvaises exigences. Le réaménagement estimé lié à ces échecs dépasse 45 milliards de dollars par an.

Do 70% of Your Projects Fail? (Part 1) — Pie

La question est — pourquoi cela se produit-il ? La réponse est double. Premièrement, les exigences métier perdent souvent de vue le client ; deuxièmement, les exigences manquent d’un cadre de référence global qui permet aux analystes d’exigences de piloter et de suivre les exigences depuis les besoins du client et la stratégie jusqu’à la solution mise en œuvre.

Pour rédiger de bonnes exigences ou des histoires d’utilisateur, suivez ces étapes :

  1. Définissez autant de personnages que possible pour représenter les utilisateurs du système. Cela vous aidera à rester centré sur le client et à piloter et suivre les exigences en fonction des besoins du client. Introduits par Alan Cooper, les personnages définissent des utilisateurs archétypaux du système — des exemples de personnes qui interagissent avec lui. Les utilisateurs n’ont pas besoin d’être ou de représenter des individus. Un utilisateur peut également représenter une organisation.
  2. Assurez-vous que vos histoires d’utilisateur suivent les « 3C » :

Minimum Viable Product Development - Define User Stories - PART 1 - Blog Systango

  • Carte — Doit être rédigée sur une carte de note ou un post-it
  • Conversation — Obtenir des informations détaillées auprès du propriétaire du produit
  • Confirmation — S’assurer qu’elle est correctement mise en œuvre. Elle doit satisfaire aux critères d’acceptation de l’utilisateur.
  1. Divisez les histoires d’utilisateur afin qu’elles soient de taille appropriée pour s’intégrer dans un Sprint. Certaines façons de diviser les histoires incluent :
  • Diviser par étapes du flux de travail
  • Diviser par canaux d’entrée/sortie
  • Diviser par options utilisateur
  • Diviser par personnage/rôle
  • Diviser par plage de données
  1. Faites en sorte que chaque histoire d’utilisateur suive le mnémotechnique INVEST :

User stories: a comprehensive guide - Justinmind

L’agilemnémotechnique INVEST, créé par Bill Wake, sert de guide pour garantir des éléments de backlog de produit de haute qualité (PBIs), généralement rédigés sous forme d’histoire utilisateur.

  • Indépendant: Les histoires doivent être aussi indépendantes que possible.
  • Négociable: Une histoire n’est pas un contrat. Une histoire est une invitation à une conversation. L’histoire capture l’essence de ce qui est souhaité.
  • Valable: Si une histoire n’a pas de valeur évidente, elle ne doit pas être réalisée.
  • Estimable: Une histoire doit être estimable ou dimensionnée afin de pouvoir être correctement priorisée.
  • Petit: Pour une itération de deux semaines, les histoires utilisateur devraient avoir en moyenne entre 3 et 4 jours de travail — au total ! Cela inclut tout le travail nécessaire pour ramener l’histoire à un état « Terminé ».Plus une histoire utilisateur est petite, plus la précision de l’estimation est élevée !
  • Testable: Chaque histoire doit être testable pour être considérée comme « Terminée ».

Leave a Reply