Lorsque le travail n’est pas terminé dans le sprint, que faites-vous ?
When Work Isn’t Finished In the Sprint, What Do You Do? par Joel Bancroft-Connors
Est-ce que vous ou votre équipe avez déjà dit :
« Nous n’avons pas terminé tout le travail de ce sprint. Nous allons découper l’histoire afin d’obtenir du crédit pour le travail que nous avons déjà réalisé. »
« C’est fait à 90%, il faut juste le tester. Passons de 13 points à 1 point pour le prochain sprint. »
« Wow, c’est bien plus que 5 points. Nous aurions dû en faire un item à 13 points. »
« Nous n’avons pas terminé ces quatre histoires, nous allons simplement les reporter au prochain sprint. »
« C’est fait, il faut juste le tester. Créons une nouvelle histoire juste pour ça et marquons celle-ci comme terminée. »
J’entends ces phrases et d’autres similaires tout le temps. L’estimation, dans des circonstances normales, est difficile. Ensuite, tenez compte de ce qu’il faut faire lorsque vos estimations étaient « fausses » et que cela devient carrément désordonné. Ces exemples sont les raisons et les scénarios les plus courants que j’entends lorsque les gens posent des questions sur la réestimation du travail.
Alors, comment ré-estimez-vous le travail inachevé ?
Réponse courte : Je ne le fais pas.
Je ne ré-estime jamais le travail qui n’est pas terminé. Il n’a pas répondu à la définition de Done et retourne dans le l’arriéré de produit (le « backlog produit ») où il pourra être pris en compte pour le prochain sprint.
L’estimation ne change pas parce que nous avons commencé ou que c’est plus difficile que nous le pensions, et nous n’obtenons aucun crédit pour un travail qui n’est pas « terminé ».
En tant que « sauveteur » chef de projet, j’aime beaucoup la simplicité de la définition de Fait (Done) (les mesures de qualité requises pour le produit). Comme le binaire n’est qu’une série de 1 et de 0, la définition de Done n’a que 2 états, « Done » et « Not Done ».
À la fin du sprint , nous examinons chaque élément du backlog produit et nous nous demandons : « Est-ce que cela répond à la définition de Done ? » Si la réponse est oui, elle va à la revue du sprint. Si la réponse est non, cela retourne dans l’arriéré de produits.
« Not Done » est également très précis : l’élément de l’arriéré de produit n’est pas utilisable et ne génère donc aucune valeur. Cela retourne dans l’arriéré de produits et je le traite comme si aucun travail n’avait été fait. C’est dans l’arriéré de produit et vous le traitez comme n’importe quel autre élément du backlog. Il a juste l’avantage de plus de « préparation ».
Pourquoi ne ré-estimez-vous pas ?
C’est une bonne question. Il y a un certain nombre de raisons de traiter un item « Not Done » comme n’importe quel autre élément de l’arriéré de produit.
Doit être utilisable
La première raison vient directement du Guide Scrum. « Afin de fournir de la valeur, l’incrément doit être utilisable. » Je ne divise pas une histoire juste pour obtenir un crédit partiel. Si j’avais pu le diviser en un travail plus petit et qu’il était encore utilisable, j’aurais déjà dû le faire en guise de préparation. Nous nous concentrons sur les résultats (la valeur) et non sur les livrables (le travail accompli).
Le code pourrit
J’ai appris cela d’un développeur expérimenté il y a des années. Même dans les environnements où la « production » ne change que tous les six mois, la base de code peut changer beaucoup en une semaine. Lorsque le travail a commencé sur la nouvelle interface de connexion, les environnements étaient à l’état X. À la fin du sprint, les environnements étaient à l’état Y et lorsque nous avons finalement terminé l’interface de connexion, deux sprints plus tard, les environnements étaient à l’état Z. J’ai vu du travail qui répondait à la définition de Done dans le sprint précédent planter le système construit parce qu’il n’a été déployé que quatre semaines plus tard. « Il faut juste le tester », est probablement tout en haut avec « qu’est-ce qui pourrait mal tourner? » dans les déclarations qui précèdent la catastrophe.
Ne prenez pas de raccourci
Ceci est étroitement lié à la pourriture du code. Si le travail n’est pas terminé dans le sprint, je ne le reprends pas dans le sprint suivant comme si rien n’avait changé. Je prends toutes les tâches (qui ne sont pas Done) et les ramène à « à faire » (To Do). Lorsque je reprends le travail, je valide à nouveau tout le travail. Non seulement le « code pourrit », mais vous avez peut-être appris quelque chose de nouveau, avez une nouvelle approche, quelqu’un d’autre a fait le travail. En revenant au tout début, vous vous assurez que rien n’a été manqué et que la qualité reste élevée.
Le tout s’équilibre
Cela entre en jeu à la fois avec un travail qui est « presque terminé » et un travail qui est « ouh la la ! C’est beaucoup plus gros que ce que nous pensions ». Vous allez reprendre un travail qui a été entrepris dans un sprint précédent et qui était à 1 point d’effort de finir, et vous allez également prendre un travail qui finira par nécessiter trois fois plus de travail que prévu, et à long terme, le tout s’équilibre. La loi des grands nombres nous dit essentiellement que, au fil du temps, le nombre d’éléments surestimés s’équilibrera avec le nombre de sous-estimés.
Ne le faites pas
Si cela n’a pas été fini dans le sprint, profitez-en pour examiner le travail à nouveau. Commencez par les critères d’acceptation. Sont-ils trop vagues ? Peut-on y répondre par oui ou non ? Regardez au-delà de cet élément de l’arriéré pour avoir une vue d’ensemble. L’équipe prend-elle trop de travail, cet élément dépendait-il d’un autre élément, y a-t-il une difficulté avec la définition de Done ?
Enfin, profitez-en pour poser la question suivante
Devrions-nous encore faire ce travail ?
Chaque sprint est une opportunité d’inspection et d’adaptation. Une partie consiste à examiner tout ce qui se trouve dans l’arriéré de produit et à vous demander si cela soutient toujours l’objectif du produit.
DantotsuPM.com 