Scrum, Agilité et Rock'n roll

Encore un effort, coco !

En préparant ma présentation "Estimations, mesures et indicateurs agiles" à l'Agile tour du 22, je revois la notion de valeur.

Avec l'expérience on donne moins d'importance aux estimations et à leur justesse, parce qu'on sait que ce qui compte avant tout c'est d'arriver, en faisant de son mieux.

Après le succès de l'Agile Tour du 16 octobre, nous reprenons les séminaires trimestriels à Toulouse. En attendant de nouvelles formules pour 2009.
Donc le prochain SigmaT, le 8ème en 2 ans, aura lieu le 12 décembre. Un programme varié, avec un retour d'expérience, de la modélisation agile et un sujet que je présenterai sur la planification de release.
Le 16 octobre nous avions distribué aux premiers inscrits des cartes de planning poker. Il nous en reste encore quelques-uns à donner le 12 décembre. Or nous n'avions pas expliqué quelle utilisation en faire lors de la conférence. L'objectif de ma présentation est de réparer cet oubli. Au-delà du simple exercice de planning poker, je présenterai, à partir de mes expériences sur les projets :

• l'estimation en points
• la mesure de la vélocité de l'équipe et son utilisation
• la planification à moyen terme, selon le type de release

Tout le détail du programme et les inscriptions sur www.sigmat.fr

Un burndown chart de release donne une bonne indication du travail qui reste à faire. En y ajoutant la consommation du budget, on obtient des indicateurs permettant de répondre à des questions fondamentales de la gestion d'un projet : où en sommes-nous dans l'avancement du projet, combien de budget avons-nous consommé ?

Seulement, et c'est normal avec une méthode agile, le périmètre initial, représenté par le point de départ d'un burndown chart, évolue toujours. Je définis ici le périmètre comme le total des points des éléments qui constituent le backlog pour une release.

Il évolue toujours, sur tous les projets auquel j'ai participé. La raison la plus évidente est l'ajout d'une nouvelle story qui n'avait pas été prévue au début du projet. Il y en a de nombreuses autres :

• la décomposition, suivie d'une estimation. Il est fréquent que le total des points des éléments décomposés ne soit pas identique au total estimé pour l'élément avant décomposition
• la suppression d'un élément. Il arrive qu'on décide de le reporter pour une prochaine release
• une ré-estimation d'un ou plusieurs éléments du backlog qui avaient été mal compris
• un élément qu'on n'avait pas encore estimé, parce qu'on n'avait pas eu le temps et/ou parce qu'il n'était pas prioritaire. Le simple fait de lui donner une estimation ajoute des points au total et modifie le périmètre.

Le burndown chart classique ne permet pas de voir l'évolution de périmètre. Pour l'avoir, il convient simplement de tenir compte de la vélocité. A la fin de chaque sprint, cela revient à faire 2 mesures : le reste à faire et la vélocité du sprint qui se finit. Les deux comptées en points.

Par exemple :

• fin du sprint 0 : 100 points à faire dans le backlog de produit
• fin du sprint 1: 82, vélocité 16
• fin du sprint 2 : 64, vélocité 19
• fin du sprint 3 : 56, vélocité 18
• fin du sprint 4: 30, vélocité 20

Cela permet de savoir que pendant le sprint 3, l'évolution de périmètre a été de 18 - (64-56) , soit une augmentation de périmètre de 10 points. Au contraire pendant le sprint 4, le périmètre a diminué de (56-30) - 20, soit 6 points.

Cela peut se voir un graphique, en voici un exemple :

En rouge la courbe de reste à faire, le burndown classique. En bleu, le reste à faire si le périmètre était resté constant, obtenu simplement en utilisant la vélocité à partir du reste à faire au départ.

Pour une méthode agile, du conseil agile.

Le temps qui passe ne se rattrape pas

Estimer devient un jeu...

Et en français !