Il est important que l'équipe comprenne que l'on ne peut pas gagner à tous les coups au BlackJack, comme on ne peut pas toujours finir une tâche en moins de temps que prévu; mais il est important que tous les membres de l'équipe se rendent compte que pour que l'on puisse rester à la table et continuer à jouer avec la croupière il faut gagner plus et perdre moins (plus tu pédales moins fort moins tu avances plus vite)...


Les développeurs sont souvent gênés d'annoncer un retard, ils commencent à être surpris quand leur ScrumMaster adoré ne leur coupe pas un doigt et non déraper ce n'est pas la fin du monde, surtout quand les tâches sont petites et que nous avons compris notre erreur....

Dans un projet "normal", les avances compensent les retards et finalement en jouant plus ou moins avec le "mou" du Sprint que l'on s'est laissé on finit pas s'en sortir...

Mais parfois, la Loi de Parkinson (« Le travail s’étale de façon à occuper le temps disponible pour son achèvement ») prend le dessus et on voit que l'on perd presque à tous les coups (ou que l'on ne gagne jamais).

C'est là que je rappelle que comme au BlackJack, si l'on veut rester longtemps il ne faut pas perdre tout le temps...

On n'est pas obligé de "sur performer" les estimations mais posons nous la question "Comment pouvons nous être plus efficace sur cette tâche ?"
Ok Brendon l'a chiffré à 5j mais c'était la semaine dernière, entre temps, on a développé d'autres modules et il doit y avoir de la "reuse" à faire (peut-être) ? Est-ce que l'on est sur que l'on a bien découpé les tâches de la Story ? Est-ce que notre enchainement des tâches est "optimisé ?

Bien sur, on fera mieux la prochaine fois mais uniquement si l'on analyse et comprend nos erreurs.
Attention à ne pas vouloir gagner à tout prix en prenant des mauvais raccourcis :

  • Code bâclé, illisible, compliqué...
  • Pas de test
  • extension des horaires de travail