Voyons comment et pourquoi nous pourrions vouloir garantir la qualité des user stories. De mauvaises user stories conduisent à des réunions inutiles, du gaspillage et des retouches. Améliorer la user story le plus tôt possible dans le cycle de vie du développement est un moyen efficace de minimiser le gaspillage et les retouches.
L'assurance qualité est une approche systématique visant à déterminer si un « produit » répond à des critères acceptables. Pour l’assurance qualité des user stories, nous devons d’abord définir à quoi ressemble le bien ? Quelle est la différence entre une bonne user stories (et un ensemble de user stories) et une mauvaise qualité.
Pour le développement de logiciels agiles, nous avons tendance à utiliser la user story comme forme abrégée d'une exigence logicielle. Certains coachs agiles peuvent contester le fait que les user stories soient effectivement des exigences, mais c’est effectivement le cas de la plupart des équipes.
De nos jours, la plupart des assurances qualité sont partiellement (ou totalement) automatisées.
Qu’attend-on d’une bonne User Story ?
Le minimum
- Nous recommandons un titre succinct et unique
- Identification claire de l’utilisateur (cohérente dans un ensemble de user stories).
- Des déclarations claires et succinctes des étapes fonctionnelles nécessaires pour satisfaire une seule exigence fonctionnelle de l'utilisateur.
Facultatif, recommandé
- Une déclaration de avantage ou "pour que"
- Une déclaration du événement déclencheur, quelles sont les circonstances de l'utilisateur qui font que cette exigence entre en jeu.
- Un identifiant de référence unique, qui ne change pas, même si la user story change.
