iceScrum | Modification des histoires finies – iceScrum

iceScrum Forums Discuss on iceScrum

Viewing 2 posts - 1 through 2 (of 2 total)

  • Author
    Posts
  • #128068

    nicolas.tartoue
    Participant

    Bonjour,

    Nous souhaiterions pourvoir modifier des histoires finies mais actuellement une histoire finie dans un sprint précédent n’est plus modifiable.

    Quelque exemple de cas:
    – des modifications ont été apportés sur l’histoire lors des développements à l’oral entre le PO et le développeur mais n’a pas été reportée dans l’histoire.
    – des précisions aurait besoin d’être apportées sur l’histoire pour éclaircir le besoin afin que le fonctionnement soit plus clair pour la TRA (Tierce Recette Applicative)
    – Idem sur les tests d’acceptances

    Est il possible de rendre ses modifications possible avec la version actuelle? Sinon pouvez vous le prévoir pour une version future?

    J’utilise la version v7.5.1 Pro actuellement.

    #128247

    Nicolas Noullet
    Keymaster

    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.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.