Limiter le bac de sprint

Lors de la planification de sprint, l'équipe se met d'accord avec le Product Owner sur une liste de stories. Elle identifie le travail à faire pour réaliser ces stories, travail qui est enregistré sous forme de tâches.

Cela présente l'avantage de permettre à l'équipe de connaitre l'ensemble des travaux attendus pour le sprint. Mais cela ne facilite pas la prise en compte des changements pendant le sprint. Il est parfois nécessaire, sans changer le but du sprint, de prendre en compte des travaux non prévus au début du sprint.

En général, une équipe réalise une dizaine de stories dans le sprint, mais à un moment donné ne travaille que sur 2, 3 ou 4 stories en même temps. Au début du sprint, le bac de sprint sera rempli avec cette dizaine d'éléments et celles sur lesquelles on ne travaille pas constituent du stock.

Pour être plus agile, on peut appliquer une limite explicite sur le nombre de stories dans le bac de sprint.

Limite de TAF sur le bac de sprint

C'est une des pratiques que je présenterai demain à Agile Grenoble.

Elle a des implications dans la planification du sprint :

  • au début du sprint on remplit le bac de sprint en s'arrêtant à la limite et donc on ne détaille le travail que de ces stories,
  • ensuite pendant le sprint, on planifie sur demande.