Le sprint est fini, et il reste des tickets

Pourquoi est-ce qu’il reste un / des tickets dans le sprint

La première étape est de déterminer pourquoi nous n’avons pas terminé le sprint.
Nous devrons également répondre à la question suivante: « Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction ».

Une question de capacité

Dans le cas d’un début de projet, il est probable que nous n’ayons pas encore trouvé notre vitesse de croisière, nous remplissons donc le sprint en tâtonnant jusqu’à savoir ce que nous sommes capables de réaliser au cours de la timebox.

Un changement dans l’équipe entraine une perturbation (dans la force).
Une personne en moins diminue d’office la capacité de réalisation de l’équipe, logique me diras tu, cependant, une nouvelle recrue va également diminuer la vélocité (dans un premier temps)
Quand un nouveau rejoint le projet, il va devoir prendre connaissance du métier, de la problématique que l’équipe résout par son travail, il va également apprendre le fonctionnement de l’équipe, et pour ce faire, les autres membres de l’équipe vont perdre investir du temps pour le former.
Donc, en plus de ne pas bénéficier tout de suite d’une augmentation de vélocité, nous allons également en perdre.

Attention, la perte de vélocité doit être à court voire moyen terme, si cette perte perdure, il faut envisager que la nouvelle recrue a été mal intégrée, qu’elle ne correspond pas au projet ou encore que l’équipe devient trop importante et ne se synchronise plus correctement.
Dans tous les cas, il faut agir.

Une mauvaise estimation

Et oui, une estimation reste une science inexacte, de temps à autre, nous nous trompons. Nous surestimons ou sous-estimons. La plupart du temps, nous arrivons à l’équilibre.

Une erreur de compréhension

Nous sommes humains, nous avons plein de possibilités de ne pas nous comprendre, alors, oui, il arrive que nous comprenions une chose alors que ce n’était pas du tout ça.

À la revue par les pairs, nous nous rendons compte que ce n’est pas du tout ce qui était demandé.

• Ah zut, je n’avais pas ben compris, et je n’ai pas anticipé ces changements, c’est plus compliqué, ça prend plus de temps …
• Ah, en fait, maintenant que j’ai compris, je vois que nous avons une dépendance vis-à-vis d’une autre équipe, d’un autre fournisseur …
• Ah, l’équipe a changé entre le moment ou ce ticket est passé à prêt et le développement (Oui oui, ça arrive)

Que faire avec les tickets que nous n’avons pas terminés durant notre sprint?

Il n’y a pas de réponse simple, c’est au cas par cas.

La logique voudrait que s’il y avait un ticket X dans le sprint venant de se terminer, c’est qu’il faut le réaliser, donc, hop sprint suivant.
Cependant …

• La fonctionnalité à développer arrive trop tard, et n’a donc plus de raison d’être.
• Le produit a pivoté, la fonctionnalité n’est donc plus aussi prioritaire, voir, plus nécessaire.
• D’autres items ayant une priorité plus élevée sont apparus dans le backlog
• L’item ne peut pas être réalisé, car il y a des dépendances non résolues

Pour ma part, je considère que si un ticket a été commencé, il est préférable de le terminer.
En effet, si nous laissons les changements tels quels, suite aux autres évolutions, le travail sera probablement entièrement à refaire pour être intégré dans la solution qui aura évolué. (Tout en prenant en compte les points précédemment cités)

Pourquoi est-ce que ceci n’a pas été anticipé durant les daily et le sprint aménagé en fonction

Heu, ben oui, en fait, il sert à quoi le daily, si ce n’est justement faire un topo sur la santé du sprint, inspecter au jour le jour que nous pouvons respecter le sprint goal et réaliser tout le contenu initialement prévu.po
Si nécessaire, nous nous devons de réaménager le contenu du sprint en accord avec les dev et le PO tout en respectant le sprint goal.

Tout ça pour dire que ça ne devrait pas arriver car nous devrions avoir géré le problème en amont.

PiPo