Comment utilisez-vous des scénarios après la création de user stories dans le backlog dans un environnement agile?
J'ai récemment rencontré le travail de Kim Goodwin où elle partage sa passion pour l'utilisation de scénarios comme outil de conception. Elle parle d'utiliser des scénarios, dans un environnement agile, pour informer la rédaction des user stories et explique que les user stories sont des fragments de fonctionnalités/tâches liées aux scénarios.
Ma question est:
Comment intégrer des scénarios dans un projet agile qui a déjà des user stories dans le backlog? Mettez-vous à jour les user stories actuelles sur le le backlog (qui sera difficile en termes de nombre de user stories déjà saisies et estimées) ou vous concentrez-vous sur l'avenir où de nouvelles user stories seront construites autour des scénarios?
Liens associés à Kim Goodwin:
Kim Goodwin - Concevoir avec des scénarios: mettre les personas au travail
Kim Goodwin - Développement de scénarios efficaces
Résumé: les scénarios fournissent un contexte aux histoires d'utilisateurs. Par conséquent, il n'est jamais trop tard. Vous pouvez découvrir de nouvelles histoires ou réaliser que les histoires existantes ne sont pas nécessaires.
Pour expliquer ma réponse, je vais commencer par les définitions du contexte.
Les user stories sont des informations discrètes et structurées qui décrivent un élément de fonctionnalité livrable et testable pour un utilisateur. (c'est-à-dire les cartes que vous verrez sur un tableau Agile)
Les scénarios tissent ces histoires ensemble montrant le contexte plus large, les rebondissements, les virages et l'interaction entre les acteurs et les canaux. (c.-à-d. comment la personne progresse au cours d'un voyage, comment les contextes changent, quelles sont les influences, etc.?) Des choses que vous pourriez ne pas avoir sur une carte d'histoire.
La construction de scénarios fournit un contexte précieux, en particulier pour ceux qui ne connaissent pas les détails du projet. Si vous découvrez que vous avez besoin d'élargir l'ensemble des histoires, vous devriez maintenant avoir un outil puissant pour justifier et communiquer cela.
Ma suggestion:
- Essayez d'utiliser les cartes récapitulatives utilisateur existantes dans votre scénario. Le devrait démontrer que les scénarios capturent beaucoup d'informations qui ne figurent pas sur les cartes. Certains de ces éléments peuvent ne pas aboutir à une nouvelle histoire si ce n'est pas une partie livrable du système.
- Cartographiez les scénarios. (par souci de concision, je n'entrerai pas dans la façon de construire des scénarios ici).
- Identifiez le (s) lieu (x) dans le scénario qui correspondent aux user stories. Cela ancrera vos histoires existantes.
- Identifiez si les scénarios révèlent de nouvelles histoires et incluez-les si nécessaire (Une meilleure compréhension du contexte peut révéler quelque chose d'inattendu).
- Vous devrez peut-être redéfinir votre produit minimum (ajouter ou supprimer des histoires en fonction de la nouvelle compréhension).
Au final, l'objectif devrait idéalement être de construire un produit répondant au mieux aux besoins de l'utilisateur en fonction de son contexte. Si le calendrier de développement ne le permet pas, vous devrez envisager plus de temps ou de ressources.