Bonjour Nicolas,
Les histoires utilisateurs n’ont pas vocation de servir de documentation fonctionnelle exhaustive du produit ; autrement dit ce ne sont pas des listes d’exigences détaillées et à jour vis-à-vis du produit comme on peut en retrouver dans un cahier des charges.
Une illustration simple de cela : imaginons qu’une fonctionnalité de notification par email fasse l’objet d’une histoire (h1). Elle est développée dans le sprint 3, tout se passe bien et l’histoire et validée par le PO. Un retour d’une partie prenante suggère la modification des règles métier qui déclenchent l’envoi d’email. Une nouvelle histoire (h2) est créée dans le backlog, décrivant seulement le résultat du changement de la règle métier, et est développée au sprint 5. Pour savoir ce qu’est censé faire l’outil sur l’ensemble de la fonctionnaltié de notification, h2 ne suffit pas, h1 non plus, il faut connaître les deux et savoir comment certaines règles d’h1 ont été rendues obsolètes par h2. Avec deux histoires c’est encore gérable, mais avec de nombreuses histoires réparties sur plusieurs sprints, on voit que ça deviendrait vite ingérable.
Les histoires sont avant tout un support de discussion entre le PO et l’équipe de développement afin que l’équipe développe la fonctionnalité attendue par le PO. Comme vous le soulignez, certaines précisions seront données par le PO à l’oral et de manière informelle plutôt qu’à l’écrit, c’est exactement le but des histoires utilisateurs et c’est même pour cela qu’on les appelle « histoires ». Cela fonctionne car la connaissance métier est diffusée et partagée par le Product Owner, notamment lors des réunions d’estimation, de planification et les revues de sprint.
Rien n’empêche d’écrire des cahiers de test fonctionnels, notamment utiles pour de la non-régression et pour avoir cette vision « à jour » de ce qu’est censé faire le produit que ne peut pas donner les histoires. Evidemment pour éviter le travail inutile, ces tests peuvent se baser sur les stories et leurs tests d’acceptation, auxquels viendraient s’ajouter les précisions que vous évoquez.
Je ne connais pas précisément votre contexte mais il semble que si il y a des testeurs et recetteurs, ils devraient être intégrés à l’équipe et ainsi bénficier de ces échanges avec le PO. Une story finie à la fin d’un sprint doit être définitivement finie. La validation des stories doit être effectuée pendant le sprint dans lequel elles sont développées, indépendemment du fait qu’il y ait ou non des cahiers de test en complément des histoires.
