Acceptation officielle du travail lors de la Sprint Review – Oui ou Non ?

Certaines équipes utilisent la Sprint Review comme une occasion de faire valider les éléments du Product Backlog terminés durant ce Sprint par le Product Owner ou les parties prenantes clés.

En principe, une Sprint Review ne devrait pas être utilisée par une équipe pour faire valider son travail par le Product Owner. L'équipe et le Product Owner devraient collaborer si étroitement pendant le Sprint que l'équipe sait déjà ce que le Product Owner pense de leur travail.

« Pas de surprises » est ma règle n°1 pour la Sprint Review

Il est tout à fait acceptable qu'un Product Owner n'accepte pas le travail de l'équipe pour un Product Backlog Item spécifique. Cependant, l'équipe devrait le savoir à l'avance.

Les membres de l'équipe ne devraient pas arriver dans un Sprint Review en s'attendant à une grande reconnaissance pour leur travail, pour ensuite recevoir des critiques de manière totalement inattendue.

Le Sprint Review peut-il être officiellement utilisé pour la validation ?

Lorsqu'un client mandate un prestataire pour développer un produit, idéalement quelqu'un au sein de l'entreprise du client assume le rôle de Product Owner. Dans ce cas, il peut être acceptable que les fonctionnalités soient validées lors de la Sprint Review. Néanmoins, je maintiens qu'il ne devrait pas y avoir de surprises lors de la Sprint Review.

Même si le Product Owner côté client donne du feedback à l'équipe pendant le Sprint, il est possible qu'il doive attendre une validation officielle jusqu'à ce que les autres parties prenantes aient eu l'occasion de s'exprimer sur le travail réalisé.

Un exemple simple

Un exemple simple : ma fille m'a demandé récemment si elle pouvait participer à une sortie scolaire. Je lui ai dit que je n'y voyais pas d'inconvénient, mais – vous l'aurez deviné – il fallait d'abord demander à sa mère. La raison était que ma femme aurait pu avoir d'autres projets pour la famille à ce moment-là, dont je n'étais pas encore au courant.

Et l'acceptation dans un vrai projet ?

C'est une situation quotidienne pour les Product Owners dans les projets de développement. Même si le Product Owner, qui interagit quotidiennement avec l'équipe, apprécie la façon dont une fonctionnalité a été construite, il doit parfois quand même s'assurer que les parties prenantes qu'il représente partagent cet avis. Bien sûr, on pourrait dire que le Product Owner pourrait simplement aller les voir et leur demander. Mais cela peut s'avérer très peu pratique et c'est donc mieux géré lors du Sprint Review.

Pour ce type de projets de développement, le client ne met cependant pas toujours un Product Owner à disposition. Souvent, le client paie pour que le prestataire s'occupe de tout.

Le client reste bien sûr le véritable Product Owner. C'est lui qui acceptera ou refusera en fin de compte le travail de développement. Mais il ne veut pas être « dérangé » quotidiennement avec ces sujets. La solution typique est alors que le prestataire fournisse un Product Owner issu de sa propre entreprise.

Et dans ce cas, aucun élément du Product Backlog ne peut être accepté ou validé avant le Sprint Review. Le véritable Product Owner (de l'entreprise du client) n'est pas suffisamment disponible et impliqué pour pouvoir valider plus fréquemment.

Certes, l'équipe peut obtenir une approbation provisoire de son propre Product Owner pendant le Sprint. Mais le vrai Product Owner de l'entreprise du client peut finalement prendre une décision complètement différente lors du Sprint Review.

La réponse définitive dépend, comme souvent, du contexte de chaque situation. C'est pourquoi je dois dire que ça ne me préoccupe pas trop si la validation officielle des travaux a lieu lors du Sprint Review. Je maintiens néanmoins qu'il ne devrait pas y avoir de surprises lors du Sprint Review. Fais ce qui te convient le mieux. L'essentiel est que les membres de l'équipe sachent avant le Review ce qui les attend.

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins.

Sprint Planning orienté vélocité

=> Avantages et inconvénients du Sprint Planning orienté vélocité

Quand faut-il modifier l'ordre des items ?

=> Voici 5 bonnes raisons pour lesquelles tu devrais de temps en temps ajuster l'ordre des items dans le Sprint.