Pyxis

Lorsque nous parlons Scrum, nous insistons sur la visibilité, l’engagement, les points d’inspection, l’adaption… ajoutons à cela quelques règles simples, 3 rôles, 5 artefacts, quelques incréments et du bon sens à volonté… et voilà une recette simple et gagnante pour une équipe agile!

Cependant, surtout dans les grandes organisations qui font le choix de l’agilité, notre équipe Scrum se retrouve bien souvent scrutée par les stakeholders, qui déplorent parfois leur manque de visibilité sur l’avancement global du projet. Certes, le Release Burndown, couplé le cas échéant au graphique de Vélocité, adresse ce besoin, mais il a une lacune majeure : il ne permet pas de rendre visible l’atteinte du périmètre minimum, ni de ce fait le levier que l’on a sur la portée.

Mon collègue Mathieu et moi-même avons envisagé un autre graphique, baptisé « Sunset Graph » (en hommage à son visuel si… jaune), dans le but d’optimiser notre communication sur l’avancement et sur les prévisions.

Ses caractéristiques? Il s’agit d’un burn-up mettant en valeur :

• Le périmètre du backlog, catégorisé en obligatoire/important/optionnel
• l’avancement réel catégorisé en obligatoire/important/optionnel
• l’avancement prévisionnel compte tenu de l’auto-évaluation de l’équipe
• la vélocité réelle de l’équipe
• les fluctuations du backlog

Par exemple : Nous sommes au sprint 0 d’un projet, et le PO a catégorisé ses stories. L’équipe fait une macro-estimation de la totalité du carnet de commande par un atelier type wall session, puis nous alimentons le graphique avec les valeurs estimées. Par rapport à l’engagement de l’équipe pour le sprint 1, nous avons le point de départ des prévisions pessimiste et optimiste. L’équipe fait ensuite des hypothèses sur sa courbe d’avancement pire et meilleure (en fonction de sa courbe d’apprentissage pressentie par exemple).

Dans l’exemple du graphique ci-dessus, on constate que selon les hypothèses, à la fin du sprint 8, on pense avoir atteint l’optionnel dans le meilleur des cas, et le milieu de l’important dans le cas pessimiste. Les courbes prévisionnelles divergent logiquement (plus on s’éloigne, moins on est précis).

Suite au sprint 0, au fil des sprints, on met à jour les données après chaque planification.

Par exemple, dans le graphique ci-dessous, au bout de 3 sprints (donc 3 sprints de données réelles), on constate que :

• le périmètre du backlog a évolué
• les évaluations des cas pessimiste et optimiste tendent à converger car l’équipe affine ses estimations
• la pente du réalisé nous montre la vélocité de l’équipe qui va en s’améliorant
• dans ce cas, suite à la révision du backlog et aux réalisations meilleures que prévues initialement, l’équipe pourrait couvrir dans tous les cas l’obligatoire et l’important du backlog.

Ainsi, ce graphique, associé au travail annexe de catégorisation du backlog et de macro estimation de ce dernier, permet :

• à l’équipe, en sprint 0, de prendre conscience de l’ampleur du backlog et des objectifs
• à l’équipe, en réalisation, de vérifier sa vélocité, la justesse des estimations, et de mieux s’évaluer
• au PO, en tout temps, de savoir ce à quoi il peut s’attendre, et si besoin d’ajuster ses priorités et/ou de jouer sur ses leviers Calendrier/Budget/Portée
• de rendre visible l’avancement du projet (atteinte du périmètre minimum), mais aussi les potentiels dysfonctionnements (ex : fluctuation forte du backlog, vélocité dégradée, …)

Tout cela favorisant la communication… CQFD!