L'élément de sprint prend plus de temps que prévu. Que devrions nous faire?

Que devons-nous faire si un article dans Scrum prend plus de temps que prévu? Je pose cette question parce que j'ai remarqué des éléments que les développeurs ont du mal à terminer car c'est beaucoup plus difficile que prévu.

Dans une telle situation, devrions-nous

• supprimer l'article du sprint dans le catalogue de produits afin que nous puissions respecter le calendrier du sprint?
• passer à un élément de sprint plus facile et laisser un sprint problématique jusqu'à la fin de la chronologie
• justifier lors de l'examen du sprint pourquoi l'élément ne peut pas être terminé au sprint actuel auprès des parties prenantes?

Comment éviter une telle situation à l'avenir? Est-ce dû à un manque de planification initiale ou nous n'avons pas fait d'effort pour décomposer l'élément sprint en élément plus petit?

Avec "item", je suppose que vous voulez dire "tâche".

La planification de l'optimisme dans le logiciel est aussi ancienne que le logiciel lui-même. La bonne chose à propos de la mêlée, c'est que vous y êtes confronté bientôt et que vous en créez la visibilité: c'est pourquoi la vitesse des équipes est basée sur des données passées et non sur des estimations futures.

Pour terminer une histoire, vous devez également effectuer les tâches qui s'avèrent beaucoup plus difficiles que prévu. Aucune excuse pour les reporter. (C'est pourquoi la Définition de Fait est si importante). Si cela signifie que l'équipe échoue à une histoire, alors tant pis, vous aurez quelque chose à dire lors de votre prochaine rétrospective. La vitesse diminuera (deviendra plus réaliste) et l'équipe apprendra à faire de meilleures estimations ou à laisser plus de marge de sécurité pour les tâches imprévues. Le propriétaire du produit aura une vue plus réaliste de sa planification de sortie.

Que devons-nous faire si un article dans Scrum prend plus de temps que prévu?

En supposant que par article, vous voulez dire histoire, à la fin du sprint, vous le remettez généralement dans le backlog du produit (et le planifiez probablement pour la prochaine itération). L'équipe ne marque aucun point pour elle dans l'itération actuelle.

Une autre alternative, si l'histoire est assez grande, est de la découper verticalement . Par exemple, le récit "recherche dans le catalogue de produits" peut éventuellement être divisé en "recherche par catégorie" et "recherche en texte intégral", mais pas en "formulaire de recherche" et "résultats de recherche".

Comment éviter une telle situation à l'avenir?

Il n'y a pas de réponse directe facile à cela. Dans la mêlée, vous effectuez des rétrospectives de sprint à chaque itération, où vous discutez généralement de ce genre de choses avec l'équipe. Il existe de nombreuses possibilités différentes:

• L'équipe, ou certains membres de l'équipe, a une mauvaise semaine
• Vos équipes pipelines travaillent les éléments horizontalement (par exemple backend-> frontend-> QA)
• Les histoires sont trop grandes par erreur
• L'équipe "plaque d'or" les histoires en ajoutant du travail supplémentaire qui n'est pas strictement nécessaire à la réalisation de l'histoire.
• Les histoires sont très grandes par nature, vous avez besoin de sprints plus longs (peu probable)
• L'équipe estime les histoires de manière imprécise (incohérente)
• Le projet a beaucoup de dette technologique / base de code pourrie et votre vitesse est trop faible
• Vous ne mesurez pas et n'évaluez pas votre capacité de sprint correctement (ou pas du tout).

etc.

Vous dites que vous ne le terminerez pas, mais ce n'est pas mal, ce ne sont que des données.

"Rencontrer la chronologie du sprint" n'est pas un objectif. Votre objectif est de compléter des user stories. La chronologie n'est qu'un outil pour vous aider à mesurer et à savoir combien de travail vous pouvez faire dans un sprint.

Si vous êtes certain que vous ne pouvez pas terminer le travail dans le sprint, une solution consiste à le déplacer vers le bas de la liste des priorités et à travailler d'abord sur les autres histoires du sprint. Ensuite, avec le temps restant, vous pouvez commencer à travailler dessus. Réestimez le travail avant le prochain sprint et terminez-le ensuite.

Assurez-vous dans votre rétrospective que vous discutez de ce qui s'est mal passé afin que vous puissiez améliorer vos estimations à l'avenir.

Si une tâche prend plus de temps que prévu, cela devrait être évoqué dans la rétrospective et discuté. Y avait-il un élément manquant dans la première analyse? Était-ce quelque chose qui n'avait pas déjà été fait souvent par l'équipe? Il y a beaucoup de raisons possibles pour lesquelles quelque chose peut prendre plus de temps que prévu initialement.

L'équipe devrait essayer de faire le mieux possible la tâche, puis dans la rétrospective, discuter des stratégies à ce sujet à l'avenir. Si l'équipe est relativement nouvelle dans l'utilisation de Scrum, cela peut faire partie du travail sur la vitesse initiale de l'équipe. Certaines équipes peuvent penser qu'elles peuvent faire 20 points et certaines équipes peuvent faire 60 points, le point est de savoir avec quelle constance le même nombre de points peut être fait à chaque sprint.

Cela se produira à l'avenir, car chaque fois que l'équipe aura de nouvelles tâches qu'elle n'a pas faites avant qu'il ne reste du temps pour résoudre les problèmes liés aux estimations. Cela fait partie du processus d'apprentissage qui ne devrait pas vraiment surprendre.

Ce que nous faisons habituellement dans notre entreprise lorsqu'une tâche commence à prendre plus de temps que prévu est de la diviser en tâches plus petites.

De cette façon, nous ne blâmons pas le développeur d'être trop lent, mais nous reconnaissons également que la tâche a été conçue de manière incorrecte.

Une autre chose pourrait être d'attribuer la tâche à un autre membre de votre équipe de développement pour éviter que votre développeur tardif ne s'enfonce dans un trou. Et si la tâche est vraiment critique, certains XP pourraient être la solution.