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.

Commentaires

1. Le jeudi 31 janvier 2008, 14:31 par Alexandre Boutin

Dans mon entreprise, je préconise de mettre dans les backlog tout ce qui apporte de la valeur ajoutée à l'entreprise et qui consomme du temps à l'équipe pour sa mise en place.

Je classe personnellement les éléments du Backlog en 3 catégories:
- Exigences Business: "Use cases" ou "User Stories"
- Exigences Engineering: Mise en place de l'intégration continue, des activités complexes (tests de performance ...) et de l'action identifiée lors de la rétrospective (oui oui, 1 seule)
- Exigences Opérationnelles: Les améliorations qui vont réduire les coûts de maintenance des environnements de production (Réduction du nombre de serveurs, Protection contre de fausses alertes dues à l'environnement extérieur ...)

La première catégorie contribue à augmenter le revenu de l'entreprise et les 2 suivantes à augmenter la marge nette (réduction des coûts de developpement et de production)

Je recommande à chaque équipe d'implémenter des exigences issues de chacune des catégories dans chaque version qui est mise à disposition des utilisateurs. Bien entendu, cela passe par une ouverture d'esprit du Product Owner pour accepter la prise en compte d'exigences à caractère technique ... mais tout cela au bénéfice de l'entreprise !

2. Le dimanche 03 février 2008, 19:48 par claude aubry

Alexandre, merci pour ce retour intéressant sur les éléments du backlog. Une question me turlupine : est-ce que les éléments des catégories que vous appelez Engineering et Opérationnelles répondent aux qualités souhaitées : suffisamment petits pour être finis en un sprint, estimables, testables ?

3. Le lundi 04 février 2008, 11:47 par Alexandre Boutin

Oui, il faut que chaque exigence puisse être implémentée durant 1 sprint et éviter les dépendances entre exigences au sein d'un sprint. Elles sont estimables et testables (mais dans certains cas le test se fait une seul fois et manuellement)

C'est parfois difficile à obtenir ... mais toujours faisable, même si l'équipe doit se forcer un peu :)