Comment bien remplir un sprint ?

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Mike Cohn
Source : How Full to Fill a Sprint
Date : 10/03/2015


Traducteur : Fabrice Aimetti
Date : 27/11/2016


Traduction :

How-full-sprint-a.jpg
Une donnée importante à prendre en considération lorsqu'on planifie un sprint en s'engageant, c'est de savoir comment bien remplir le sprint. Pour répondre, il faut d'abord comprendre qu'un sprint embarque trois structurations du temps.

La première structure du temps concerne les activités indirectes dans l'entreprise. Cela comprend tout ce qu'il faut pour être un bon citoyen dans le monde des entreprises d'aujourd'hui. Donc le temps consacré aux réunions de l'entreprise, à la lecture des mails, aux formations de sensibilisation aux RH, et même à participer aux différentes réunions prévues dans le processus d'une équipe agile.

La deuxième structure de temps est le temps planifiable. C'est le temps que les membres de l'équipe peuvent planifier pour réaliser le travail au cours du sprint. Un membre de l'équipe ne souhaitera cependant pas trop remplir le sprint. Les membres de l'équipe doivent en effet laisser de la place pour le temps non planifié, qui est la troisième structure du temps.

Le temps non planifié prend en compte trois choses :
  1. Les urgences : par exemple, le serveur tombe et on demande à l'équipe de le le réparer.
  2. Les tâches qui deviennent plus grosses que prévu. Par exemple, lors de la réunion de planification, vous aviez prévu qu'une tâche prenne 8 heures. Un peu plus tard, après avoir passé 6 heures dessus, vous vous rendez compte qu'il vous reste encore 6 heures à faire pour la finir.
  3. Les tâches qui n'ont pas été identifiées lors de la planification de sprint. Peu importe l'effort que vous avez consacré à la planification de sprint, vous ne pouvez pas penser à tout.


Graphiquement, je représente le sprint comme un rectangle avec des zones, comme ci-après :
How-full-sprint-b.jpg
La première chose que nous mettons dans le sprint ce sont les activités indirectes de l'entreprise. Puis les membres de l'équipe chargent le sprint avec le temps planifiable, mais en prenant soin que le moindre problème ne cause pas un débordement du sprint. Ils laissent de la place en haut du rectangle pour le temps non planifié, les urgences, les tâches qui grossissent et les tâches non prévues initialement.

Déterminer comment une équipe pourrait remplir un sprint pose la question sur ce qui est réellement planifiable. Considérons deux équipes. La première fait partie d'une grande organisation avec beaucoup d'activités indirectes.

Cette équipe est responsable du support de la couche middle office d'une application existante qu'il faut migrer vers un produit de nouvelle génération. Cette équipe n'a pas du tout de temps planifiable.

Le seconde équipe comprend deux développeurs dans un garage qui travaille sur le premier produit de leur startup. Pour eux, l'activité indirecte principale est qui va commander le repas du jour. Cette équipe dispose de beaucoup plus de temps planifiable que la première équipe.

De la même manière, considérons une super équipe agile qui n'arrive pas à planifier son travail. Elle ne sait absolument pas le faire. Les membres de l'équipe pensent que quelque chose prendra deux heures et cela en prend en fait 10. Ils bâclent la planification et échouent donc à identifier la plupart des tâches qu'ils auraient pu identifier initialement en y consacrant plus de temps.

Ils sont tellement mauvais dans leurs estimations qu'ils sont contraints de laisser une grande place au temps non planifié dans leur sprint. Leur temps planifiable sera inférieur à celui d'une équipe équivalente qui sait mieux estimer.

Cela veut dire que la quantité de temps planifiable ne peut pas constituer une bonne mesure des efforts de l'équipe et de son efficacité.

Si vous êtes une équipe agile expérimentée, vous savez que votre temps planifiable est aussi l'axe vertical de votre burndown chart de sprint. C'est parfois ce qu'on appelle la capacité de l'équipe. C'est différent de la vélocité, qui doit toujours être mesurée dans la même unité de mesure que les éléments du backlog produit de l'équipe, généralement en points de story.