J'ai lu beaucoup de choses sur Scrum ces derniers temps, et j'ai trouvé ce qui me semble être des informations contradictoires sur la question de savoir s'il est correct ou non de modifier le backlog du sprint pendant un sprint. L' article de Wikipédia sur Scrum dit que ce n'est pas bien, et divers autres articles le disent également. Mon professeur de développement logiciel a également enseigné la même chose lors d'un aperçu de la mêlée.
Cependant, j'ai lu Scrum et XP dans les tranchées et qui décrit une section pour les éléments non planifiés sur le tableau des tâches. Alors j'ai recherché le Scrum Guide et il dit que pendant le sprint "Aucun changement n'est fait qui affecterait le Sprint Goal" et dans la discussion sur le Sprint Goal "Si le travail s'avère différent de ce que l'équipe de développement attendait, puis ils collaborent avec le Product Owner pour négocier la portée du Sprint Backlog au sein du Sprint. " Il poursuit en disant dans la discussion du Sprint Backlog:
Le Sprint Backlog est un plan avec suffisamment de détails pour que les changements en cours puissent être compris dans le Daily Scrum. L'équipe de développement modifie le Sprint Backlog tout au long du Sprint, et le Sprint Backlog apparaît pendant le Sprint. Cette émergence se produit lorsque l'équipe de développement travaille sur le plan et en apprend plus sur le travail nécessaire pour atteindre l'objectif de sprint.
Comme de nouveaux travaux sont nécessaires, l'équipe de développement les ajoute au Sprint Backlog. Au fur et à mesure que le travail est effectué ou terminé, le travail restant estimé est mis à jour. Lorsque des éléments du plan sont jugés inutiles, ils sont supprimés. Seule l'équipe de développement peut modifier son backlog de sprint pendant un sprint. Le Sprint Backlog est une image en temps réel très visible du travail que l'équipe de développement prévoit d'accomplir pendant le Sprint, et il appartient uniquement à l'équipe de développement.
Donc, à ce stade, je suis tout à fait confus. En y réfléchissant, il est plus logique pour moi d'adopter la deuxième approche. Les éléments individuels et spécifiques dans le carnet de commandes ne me semblent pas être la chose la plus importante, mais plutôt l'objectif de sprint, donc ne pas changer l'objectif de sprint mais pouvoir changer le carnet de commandes est logique. Par exemple, si le propriétaire du produit et l'équipe pensaient être sur la même page à propos d'une histoire, mais au fur et à mesure que le sprint progressait, ils ont compris qu'il y avait un malentendu, il semble logique de changer les tâches qui composent cette histoire en conséquence. . Ou s'il y avait une histoire ou une tâche qui a été oubliée, mais qui est nécessaire pour atteindre l'objectif de sprint, je pense qu'il serait préférable d'ajouter l'histoire ou la tâche à l'arriéré pendant le sprint.
Cependant, il y a beaucoup de gens qui semblent assez catégoriques que tout changement dans le backlog de sprint n'est pas correct. Suis-je en train de mal comprendre cette position? Ces gens définissent-ils différemment le backlog de sprint d'une manière ou d'une autre? Ma compréhension du backlog de sprint est qu'il se compose à la fois des histoires et des tâches dans lesquelles elles sont réparties.
Quoi qu'il en soit, j'apprécierais vraiment la contribution sur cette question. J'essaie de comprendre à la fois quelle est l'approche de scrum idéaliste pour changer le backlog de sprint pendant un sprint, et si les personnes qui utilisent Scrum avec succès pour le développement permettent de changer le backlog de sprint pendant un sprint.