Bien que l’ajout de tâches qui ne sont pas liées à l’objectif du sprint 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.
“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 !
Edit 08/2024 : Sans compter qu’il faut être super précis et avoir une estimation très juste pour considéré qu’on ne va pas mettre en péril le sprint en gardant cette capacité. Car oui, quand on dit qu’on garde cette capacité, on sous-entend que nos estimations sont parfaites et juste et qu’il n’y aura pas de surprises dans notre plan, bref, on a déjà décidé qu’on allait suivre le plan à tout prix.
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 ?
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.
- 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.
- 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 ?