Trucs et astuces – Partie 3 de la rédaction d’une user story / Blogs / Perficient

Ce blog est le troisième et dernier article d’une série sur l’exploitation Histoires d’utilisateurs pour améliorer les résultats des produits. Dans cet article, nous explorerons comment l’utilisation de quelques trucs et astuces simples peut aider à créer un arriéré significatif de témoignages d’utilisateurs précieux.

Quels sont les « 3 C » en Agile ?

L’un des principes clés d’Agile est l’accent mis sur les 3 C ; Card, Cconversation, et Cconfirmation. Ces 3 C jouent un rôle crucial dans la définition et la priorisation du travail de vos équipes de livraison. Explorons chacun de ces trois C plus en détail.

1. Card : Écrit sur une carte physique (ou numériquement dans un outil Agile, ou une feuille de calcul si rien d’autre) et peut être annoté avec des notes sur les besoins de l’utilisateur. Cela deviendra essentiellement votre user story.
   1. Exemple : En tant que conjoint, je souhaite un garage propre pour pouvoir garer ma voiture et ne pas trébucher en me dirigeant vers la porte.
2. Cconversation : détails de la conversation avec le propriétaire du produit, les parties prenantes, les développeurs et les testeurs. Ce dialogue entre l’équipe et l’utilisateur est nécessaire pour clarifier les détails et les hypothèses de l’histoire.
   1. Exemple : Et les vélos ? Oh ouais, on peut les raccrocher !
3. Confirmation : Il s’agit d’un ensemble de critères ou de tests qui vérifient que l’histoire est terminée et répond aux attentes de l’utilisateur. Il s’agit des critères d’acceptation de votre histoire pour confirmer « l’exactitude » de l’histoire.
   1. Exemple : les outils ont été rangés, les objets ne traînent pas sur le sol et les vélos ont été suspendus.

Cet exemple peut ou non provenir d’un scénario personnel, donc je peux ou non avoir un garage propre maintenant et je n’ai pas à craindre de mourir en franchissant la porte ! 😉

Si vous vous souvenez, du blog user story n°1 de cette série, ce sont tous des composants d’une user story et, dans la méthodologie Agile, servent de principes directeurs pour une gestion efficace du travail. Ils soulignent l’importance d’éléments de travail clairs et concis, d’une communication collaborative et d’une validation continue. Cela permet aux équipes de rationaliser leurs processus, de favoriser la collaboration et d’offrir de la valeur client.

Qu’est-ce que « INVEST » et comment cela contribue-t-il au succès de ma user story ?

Pour garantir que vos user stories sont efficaces, elles doivent répondre aux critères « INVESTIR ». Ce critère acrostiche est le suivant :

• jeindépendantes : les user stories doivent être indépendantes les unes des autres, afin de pouvoir être travaillées et testées séparément.
• Nnégociable : les user stories doivent être négociables et ouvertes à la discussion et au changement.
• Valuable : les user stories doivent apporter de la valeur à l’utilisateur et à l’entreprise.
• Estimable : les user stories doivent être estimables en termes de temps et d’efforts requis.
• Small : les user stories doivent être suffisamment petites pour être complétées en un seul sprint.
• Testable : les user stories doivent être testables, afin qu’elles puissent être validées et vérifiées.

INVEST vous aidera à vous souvenir d’un ensemble de critères largement acceptés, ou d’une liste de contrôle, pour évaluer la qualité d’une user story. Si votre histoire ne répond pas à l’un de ces critères, l’équipe souhaitera peut-être la reformuler, voire même envisager une réécriture complète. En garantissant que les user stories répondent aux critères INVEST, nous pouvons rédiger des user stories plus efficaces, axées sur la création de valeur pour l’utilisateur et l’entreprise.

Vos histoires sont-elles « tranchées verticalement ? »

Parallèlement aux critères INVEST, il est recommandé d’utiliser l’approche « Vertical Slice » dans la mesure du possible dans votre backlog produit. Cela signifie que chaque user story doit fournir des tranches verticales complètes de fonctionnalités sur différentes couches de travail. Il s’agit d’un élément de travail qui apporte un changement précieux dans le comportement du système dans lequel l’équipe devra probablement toucher à plusieurs couches architecturales pour mettre en œuvre le changement.

En d’autres termes, vous n’avez pas besoin de créer une user story distincte pour le développement de l’interface front-end/utilisateur, l’architecture du système back-end, les éléments de base de données ou même les tests. Tous ces différents composants de développement et d’assurance qualité doivent être travaillés au sein du même élément de travail du backlog pour offrir de la valeur à l’utilisateur une fois que toutes les « parts du gâteau » sont considérées comme terminées.

Conclusion

En suivant ces meilleures pratiques Agile, vous comprendrez parfaitement comment rédiger des user stories efficaces qui aideront les équipes de développement à créer des produits de haute qualité qui répondent aux besoins des utilisateurs et apportent de la valeur à l’entreprise.

Dans les prochains articles du blog, nous plongerons dans la création et le développement de fonctionnalités et d’épopées.