Remplir son sprint ou garder de la capa pour la prod ?

Bien que l’ajout de tâches pendant le sprint n’est absolument pas conseillé, dans les faits les équipes y sont régulièrement confrontées. Dans ce cas comment accueillir ces tâches perturbatrices pour le sprint dans les meilleurs conditions ?

Je connais deux écoles qui se confrontent sur la méthode; garder de la capacité libre dans le sprint, ou remplacer les éléments du sprint par ces nouveaux.

Garder de la capa pour la prod

Garder de la capa pour les incidents de production (ou pour n’importe quel type d’urgence), c’est choisir des éléments de backlog à embarquer dans le sprint tout en réservant une partie “vide” du backlog pour les imprévus.

De la place est laissée dans le backlog du sprint

“On a une vélocité de 20 points par sprint, on prends 15 points d’US et on garde 5 points pour les incidents de prod”.

Et les incidents de prod arrivants, les 5 points sont effectivement “dépensés” et souvent priorisé au maximum.

Je suspecte même que certains bugs ou incidents sont estimés… pour rentrer dans cette capacité “tampon”, mais c’est parce que je vois le mal partout sûrement !

Remplir son sprint

Une autre façon de faire est de remplir son backlog de sprint normalement, avec ce que l’équipe pense pouvoir faire.

Que se passe-t-il alors en cas d’imprévu ou d’incident à réparer d’urgence ?

Les nouvelles tâches peuvent trouver leur place et leur coût est visible

C’est effectivement plus compliqué que dans le cas où de la capacité est réservée à l’avance, mais c’est pour la bonne cause.

1. L’impact de ces nouvelles tâches est alors visible. Comme la durée du sprint ne peut être étendue, une tractation est nécessaire pour échanger ces nouvelles tâches contre des tâches prévues, pour un total équivalent. On sait alors ce que l’ajout des tâches a coûté en terme de décalage de feature, on peut l’expliquer en revue de sprint. 2. La priorisation des tâches ajoutées peut être discutée. En effet, en voyant que telle feature sera décalée, le PO peut choisir si la nouvelle tâche est vraiment prioritaire ou non. Corriger un bug qui coûte 500 € par jour tant qu’il est là en décalant une feature qui rapporte 1000 € par jour n’a pas de sens, tout comme corriger en urgence un bug touchant 1 utilisateur peut être moins prioritaire que d’ajouter une fonctionnalité améliorant la vie de dizaines de milliers d’autres utilisateurs.

Conclusion

Quoi que vous utilisiez ou que vous décidiez d’utiliser avec votre équipe, l’important est d’avoir une bonne visibilité de l’impact de ces tâches indispensables mais néanmoins perturbatrices pour le sprint, pour ne pas générer de Shadow-Velocité tout comme je conseillais déjà de visualiser clairement la dette technique.

Et vous, comment visualisez-vous l’impact des tâches ajoutées au sprint ? Est-ce que les incidents sont ajoutés en priorité haute aveuglément ?