Utiliser le release Burn-Up chart pour piloter un projet SCRUM .

Pour moi, la quasi-totalité des besoins de visibilité pour piloter un projet SCRUM peut être couvert au travers de l’un des artefacts de la méthode : le release Burn-Up chart.

Le « burn-up » est l’outil de suivi de l’avancement des réalisations. Il permet de garder une visibilité sur le planning et sur le périmètre de l’ensemble du produit.

Ce graphique se source directement sur le BackLog Produit afin de connaitre la vélocité moyenne de l’équipe ( à comprendre : la capacité de l’équipe à réaliser les US) la quantité d’US déjà réalisées et la quantité d’US restantes.

Petit aparté :

Chaque US est pesée par l’équipe en Story points. Ces points correspondent à l’effort nécessaire à l’équipe pour réaliser cette US. Ce qui est visualisable dans un premier temps sur le burn-UP est donc l’ensemble des Story Points réalisés et restants à réaliser.

Ex de Burn-UP :

Sur ce Burn-UP nous voyons :

-          L’effort total, correspond au nombre de points total du backLog. On peu y a analyser les ajouts de besoins et les annulations d’histoires.

-          L’effort réalisé, correspond au nombre de points des US réalisées et donc aux fonctionnalités prêtes à être déployées.

-          L’effort linéaire réalisé, qui grâce à la vélocité moyenne de l’équipe nous donne une projection de réalisation dans le futur. ( Attention, la vélocité moyenne est affinée avec l’avancée des sprints et la montée en maturité de l’équipe, l’effort linéaire réalisé n’est donc probant qu’après un certain nombre de sprints. )

-          L’effort démarré en réalisation, correspond à ce que l’équipe a pris en charge dans un sprint, le delta avec l’effort réalisé correspond donc aux US démarrées mais non terminées.

-          L’effort prêt à la réalisation est plus rare sur les burn-UP, il permet de connaitre les US prêtes à la réalisation, c’est surtout utile pour gérer l’activité de préparation des histoires du PO qui doit s’assurer que l’équipe ne tombe pas en panne d’histoires à réaliser.

Le burn-UP nous donne donc une visibilité sur l’activité de l’équipe, nous pouvons aussi en tirer d’avantage, si nous poussons la projection linéaire dans le futur, nous pouvons estimé la date nécessaire à l’équipe pour réaliser l’ensemble du backLog :

Le Product Backlog étant priorisé par fonctionnalités métiers et les US réalisées en conséquences, nous pouvons aussi estimer la date de réalisation des principales fonctionnalités en empilant les US correspondantes, nous pouvons même simuler une date de release afin de voir ce qui est exploitable à cette date.

Le BURN-UP se basant sur le Product Backlog, celui-ci doit être complet, maintenu et toutes les histoires doivent être pesées par l’équipe.