Lors des formations "Scrum" que j'anime de temps à autre plusieurs personnes me posent la question sur le moment idéal de la validation des User Stories par le PO dans un Sprint en Scrum, autrement dit quand est-ce que le Product Owner regarde le produit et donne son retour et feedback ? Alors ma réponse peut être divisée en 2 parties à savoir :
Il n 'y a pas de réponse universelle dans ce sens, car même dans le "Scrum Guide" rien n’indique que le Product Owner doit tester les User Stories du Sprint Product Backlog “DONE” à la fin du Sprint ou au milieu du cycle itératif.Il existe plusieurs techniques et pratiques appliquées dans ce sens.
J'ai essayé à travers cet article de présenter certaines pratiques et cas de figure à propos de cette notion de validation des US pour le PO.
1. Validation continue : Cette pratique nommée aussi "Feedback au fil de l'eau" consiste à faire appel au Product Owner à chaque fois que l'équipe de développement termine une "User Story" afin de récolter les feedbacks rapidement et rectifier si nécessaire avant la fin de Sprint.
2. Validation par lot : L'équipe de développement dans ce cas de figure va fixer des créneaux avec le PO pour valider les User Stories terminées (Par exemple un Workshop au milieu de Sprint et un autre un jour avant la Review), ou avec une cadence liée à la disponibilité du Product Owner. On trouve aussi la pratique du "Freeze Time" que je vais traiter dans un article ultérieurement.
3. Validation lors de la Review : Dans ce cas de figure l'équipe de développement va attendre la fin de Sprint, pour donner la main au PO pour valider les User Stories terminées lors de la séance du Sprint Review dans la présence des parties prenantes et utilisateurs finaux.
Même parfois l'équipe de développement peur appliquer le concept du déploiement continu dans un environnement de test accessible par le PO et les parties prenantes (Recette par exemple) afin de tester rapidement ce qui est terminé, récolter les feedbacks, et rectifier si nécessaire avant la fin du Sprint.
Quel que soit la pratique choisie par l'équipe, l'objectif principal est toujours d'avoir un feedback rapide et une préparation d'un incrément produit de qualité sans bug répondant au besoins et exigences du client.
Conclusion :
Chaque équipe Scrum a son propre contexte, environnement de travail et organisation opérationnelle, donc c'est selon ces critères qu'il faut bien choisir la bonne et trouver les bons moments pour valider ce qui est terminé par le Product Owner.
L'implication des différents rôles dans Scrum est indispensable pour la réussite d'un projet agile, et plus précisément on peut dire que si le Product Owner est bien impliqué, alors l'équipe de développement peut trouver sa cadence de travail et production.
Comments