Le backlog Produit, première source d'indicateurs

La visibilité et la prédictibilité des produits développés selon les méthodes agiles représentent aujourd'hui un sujet récurrent. La "nouveauté" de ces méthodes maintenant passée, les décideurs et partie-prenantes demandent du concret. Quand le produit sera-t-il livré ? Combien coûte une fonctionnalité (en moyenne) ? Etc. Le Product Owner, de part son rôle au sein d'une équipe agile, peut consolider certains indicateurs. Parmi ses attributions, le Product Owner est le garant du backlog (liste des fonctionnalités attendues du produit). Il doit donc pouvoir à tout instant connaître la santé de ce dernier. Le backlog est, bien sûr, l'artefact principal d'une équipe agile et permet d'organiser la livraison du produit de manière incrémentale et itérative mais il représente également une mine d'or d'informations.

Quand mon produit sera-t-il terminé ?

Parmi les pratiques classiques recommandées par la méthode Scrum, l'équipe suit un Burn Down Chart qui se présente comme ceci :

Ce graphe permet de projeter une date de fin théorique à partir de la pente. Les limites de cette représentation sont néanmoins assez vite atteintes. Quid de l'évolution du périmètre ? Il est ainsi préférable de suivre le graphique suivant :

Ce Burn Up Chart modifié permet de suivre l'avancement du produit au regard de l'évolution du périmètre. La date de fin projetée est alors plus fiable. Ce graphique peut être assorti des indicateurs suivants :

• date de fin projetée,
• deadline initiale,
• écart entre les deux dates,
• tendance (l'écart a-t-il augmenté, diminué ou est-il resté stable au court du dernier sprint ?).

L'équipe aura une visibilité forte sur l'état d'avancement du produit et la date de livraison projetée.

Quand pouvons-nous livrer un produit minimum ?

La deadline de livraison d'une première version du produit, définie en amont, correspond rarement à la date projetée après quelques semaines de développement. Le périmètre évolue au gré du besoin mais aussi des bugs générés par fonctionnalité. Dans une démarche de projet agile, le PO se retrouve face au triangle de décision suivant.

En effet, la qualité n'est pas négociable, il peut donc jouer sur les leviers coût, délai et périmètre :

• décaler la date de livraison autant que nécessaire pour respecter les coûts et le périmètre initial,
• négocier une enveloppe budgétaire complémentaire afin de respecter le délai et livrer le périmètre initial,
• arbitrer son périmètre afin de livrer à temps et sans dépasser le budget.

En pratique, le PO arbitre le plus souvent le périmètre puisqu'il a la main dessus. Deux graphes permettent de lui faciliter la prise de décision.

Priorisation des MMF par la valeur

Ce premier histogramme met en avant une dispersion potentielle des équipes (si toutes les MMF - Minimum Marketable Feature - ont été débutées en parallèle) et permet de garder en tête les MMF prioritaires et donc la priorité des User Stories associées. Le Product Owner peut s'appuyer dessus pour reprioriser son backlog.

Complétion des MMF

Ce radar donne une vision complémentaire de l'histogramme. Il peut servir de support à un produit minimum. Il suffit de définir l'ensemble des MMF qui font partie du produit minimum et de positionner ensuite l'avancement de la version sur ce radar.

Quels indicateurs avec ces graphiques ?

Le côté très visuels des graphes décrits ci-dessus permet au Product Owner de voir en un coup d'oeil l'état de santé de son produit. Il est également simple de suivre les indicateurs suivants à partir des graphes à jour :

• date de fin projetée, deadline initiale, écart entre les deux et tendance de cet écart,
• nombre de stories réalisées lors du dernier sprint et tendance (améliore-t-on la vélocité ?).

Conclusion

Le Product Owner peut aisément, à partir du backlog, suivre des graphiques et des indicateurs. Il peut ainsi montrer aux décisionnaires et parties-prenantes l'état d'avancement du produit à tout moment. Il peut également arbitrer et piloter au mieux et de manière éclairée le développement du produit. Enfin, il sait où il en est et peut donc s'améliorer et aider l'équipe à s'améliorer dans une logique d'amélioration continue. La culture de la mesure est une des clés de cette dernière.

Pour compléter la vision du développement du produit, d'autres indicateurs peuvent également être suivis autour de la capacité de l'équipe, de la qualité du logiciel produit ou encore du budget. Le Scrum Master ou le directeur de programme pourront suivre ces aspects.
Xebia proposera en septembre un outil, Bee, qui centralisera et calculera l'ensemble de ces éléments.