La visibilité et la prédictibilité des produits développés selon les méthodes agiles représentent aujourd'huiun 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 Manager, de par son rôle au sein d'une équipe agile, peut consolider certains indicateurs. Parmi ses attributions, le Product Manager est le garant du backlog (liste des fonctionnalités prévues pour le produit). Il doit donc pouvoir à tout instant connaître la santé de ce dernier. Le backlog est 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 itération sera-t-elle terminée ?
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 suivre l'avancement des développements grâce à une représentation graphique du périmètre restant à faire, c’est-à-dire l’ensemble des User Stories (estimées au préalable, notamment lors du backlog refinement) qui ne remplissent pas encore les critères de votre Definition of Done.
En mettant régulièrement à jour le burn-down en fonction du rythme réel de développement, il est plus facile de comparer l'avancement des développements à vos prévisions.
Là où le burn-down chart est surtout adapté à l'échelle d'un sprint, on utilise souvent plutôt un burn-up chart pour faire un suivi sur plusieurs sprints ou semaines :
En mesurant la vélocité ou le débit de façon régulière, vos hypothèses se précisent sur :
- La date d’atterrissage du périmètre choisi (MVP, 1ère version…) et son écart potentiel avec la date prévue initialement
- Le périmètre que vous serez en mesure de livrer à une date donné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 PM se retrouve face au triangle de décision suivant :
- 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 PM arbitre le plus souvent le périmètre puisqu'il a la main dessus.
Lors de cette phase d'arbitrage, il est primordial de s'aligner avec ses parties prenantes (équipes marketing ou commerciales, customer success managers..) et de leur communiquer toute décision qui pourrait être prise sur le périmètre fonctionnel de votre produit ou la date de livraison prévue. En effet, ces équipes dépendent de vous et devront probablement adapter leur approche en fonction des évolutions de planning.
Conclusion
Le Product Manager 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.
