Le backlog de produit n'est pas une todo liste
Un élément du backlog doit amener de la valeur, en principe
Dans un commentaire de mon dernier billet sur les exigences non fonctionnelles, JML suggère de mettre également dans le backlog de produit les actions décidées lors de la rétrospective. Il donne l’exemple de l’automatisation des tests d’intégration pour les lancer lors du build.
Par ailleurs, je découvre aujourd’hui, dans le backlog d’un des projets que je suis à distance sur GoogleDocs, un nouvel élément qui est intitulé : préparation de la revue.
Dans le premier cas, c’est discutable et dans le second, c’est carrément une confusion avec un relevé d’activité.
Les réunions Scrum ne sont évidemment pas à mettre dans le backlog de produit, ni même dans le backlog de sprint. Ces réunions font partie du processus. L’équipe pourrait rétorquer qu’elle a mis préparation en pensant y passer pas mal de temps. Ce n’est pas une bonne idée non plus, la préparation de la revue de sprint ne doit pas excéder une heure. Ce n’est pas une présentation enjolivée, l’équipe montre simplement ce qu’elle a réalisé.
Dans le premier cas, on peut discuter sa présence dans le backlog parce que cet élément n’apporte pas de la valeur métier. N’oublions que c’est le Product Owner qui est responsable du backlog et qui définit les priorités. Il faudrait avoir un Product Owner très technique dans l’exemple de JML. Si c’est le backlog d’une équipe support qui développe des outils ça se comprend. Si c’est pour ajouter à un backlog contenant des vraies stories qui apportent de la valeur, c’est plus discutable. Il y a de meilleures solutions pour enregistrer les résultats d’une rétrospective.