Je ne parlerais pas dans cet article de la gestion de projet agile (Burndown chart, Dashboard …) mais de la gestion de produit agile et en particulier d’une métrique que je recommande de rendre visible pour connaître ce que l’équipe a fait lors des itérations précédentes.

La plupart des produits sont à la fois en phase de maintenance (des versions précédentes) et de développement (la version à venir), et il est toujours intéressant de connaître le temps passé par l’équipe dans les 2 activités.

Dans les approches traditionnelles, l’équipe est supposée remplir des feuilles de temps détaillées qui indique les heures passées en maintenance et celles passées en développement. La saisie de ces informations est fastidieuse, mal perçues par l’équipe et de plus, certaines activités comme la validation finale ou le refactoring ont du mal à être classé dans l’une ou l’autre des catégories.

Au bilan les informations recueillies sont erronnées et ne peuvent/doivent être utilisées pour prendre des décisions.

Mais que faire ?

Scrum nous propose une solution toute simple grâce à la mise en place d’estimation des fonctionnalités en « points d’utilisateurs ». Il suffit de catégoriser les « user stories » dans le product backlog et, à l’issue de chaque itération, de rendre visible ce qui a été produit sous forme de ratios.

Les 4 catégories que je préconise sont :

• Fonctionnelle : La User Story apporte une valeur ajoutée directe à l’utilisateur final
• Non Fonctionnelle : La User Story est en général à l’initiative de l’équipe technique et à pour but d’améliorer le processus de développement
• Bug : La correction d’un défaut connu a été planifié lors de l’itération
• Urgence : L’équipe est intervenue pour résoudre un problème (généralement en clientèle ou sur les plateformes de production)

Pour la catégorie « urgence », il est nécessaire de mesurer le temps passé (par exemple lors de chaque Stand Up) sur chacune des urgences. Le ratio des urgences se calcule donc par rapport à la capacité de production initiale de l’équipe et non sur la complexité (pas de « points d’utilisateurs » dans ce cas).

Comment utiliser cette métrique ?

De beaucoup de façons différentes, entre autres :

• Pour le Product Owner à évaluer la quantité réelle de nouvelles fonctionnalités que l’équipe est capable de produire par itération
• Pour l’équipe à argumenter la nécessité d’implémenter des tâches non fonctionnelles (voir même définir un seuil minimum)
• Pour l’équipe complète de mesurer l’efficacité de la mise en place de pratiques d’ingénierie spécifiques (TDD, Pair Programming, IC …) sur la qualité des livrables (moins de bugs, moins d’urgence …)
• Pour le Manager … de lui donner de la visibilité sans effort … même si cette métrique ne lui est pas d’une grande utilité

La mise à disposition de cette information nécessite l’ajout d’une colonne dans  le backlog puis de comptabiliser en fin d’itération les User Story « DONE » dans chaque catégorie … et le résultat est disponible en moins de 5 minutes … plus 1 minute pour l’imprimer et l’afficher.

Simple non ?