Confus de modifier le backlog de sprint pendant un sprint

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.

Tout d'abord, je n'aurais pas de règles strictes à ce sujet; le but de la mêlée est de vous permettre de vous adapter à la situation. Vous devriez donc être en mesure de modifier le backlog du sprint pendant le sprint si vous le devez absolument (comme si vous aviez oublié quelque chose de critique).

Mais dire cette modification du backlog de sprint pendant le sprint devrait être résisté. L'intérêt du sprint est que de nouveaux travaux peuvent être ajoutés au sprint suivant (après avoir été correctement hiérarchisés) sans affecter la chronologie globale du projet (plusieurs sprints).

Mais si le travail est critique pour l'une des tâches de ce sprint, vous avez deux options.

1. Ajoutez un nouvel élément au sprint.
   MAIS retirez un objet de taille équivalente du sprint.
2. Supprimez l'élément qui était mal planifié de ce sprint (afin de pouvoir le planifier correctement lors du prochain sprint).
   • Ajout d'une alternative (de taille appropriée) à partir du haut du carnet de produit (qui devrait avoir été dans l'ordre de priorité de votre réunion de planification de sprint).
   • Ou lorsque tous les éléments de sprint sont terminés, permettez aux développeurs de prendre du mou dans le carnet de commandes du produit.

Je suis donc dans le camp que vous ne devriez probablement pas modifier l'arriéré de sprint. Mais vous devez tenir compte de la situation, il peut y avoir des circonstances exceptionnelles. Dans la plupart des cas, j'irais avec les options 2 et laisserais les développeurs prendre le relais avec les tâches du backlog.

Lors de la prochaine réunion de planification, la nouvelle tâche sera analysée de manière appropriée et ajoutée au sprint (le cas échéant).

N'oubliez pas que le sprint est court et juste la marque de la prochaine goutte et non la fin du cycle de développement. Le propriétaire du produit devrait être très désespéré pour une fonctionnalité qu'il ne pouvait pas attendre la fin du prochain sprint.

La confusion est due à un langage ambigu.

Le Sprint Backlog a deux niveaux de détail. Tout d'abord, il s'agit d'une liste d'articles (User Stories) que l'équipe s'est engagée à livrer. Deuxièmement, ce sont toutes les TÂCHES que l'équipe a l'intention de faire pour livrer chacune de ces histoires.

Ainsi, lorsque les gens parlent du Sprint Backlog, ils devraient vraiment être clair sur ce qu'ils veulent dire. Lorsque vous lisez le Scrum Guide, vous verrez qu'il indique: Le Sprint Backlog est l'ensemble des éléments du Backlog de produit sélectionnés pour le Sprint, plus un plan pour fournir l'incrément de produit et réaliser l'objectif de Sprint.

Il s'agit donc à la fois de la liste des éléments du backlog produit ET du plan (tâches) pour les livrer.

Maintenant, de nombreuses équipes aiment ajouter toutes les tâches proposées (plan) au début du Sprint afin de pouvoir suivre un tableau de burndown en fonction des heures restantes à faire. D'autres équipes laissent les tâches émerger au besoin. C'EST quand il est OK d'ajouter au 'Sprint Backlog', puisque l'équipe doit le faire afin d'inspecter et d'adapter afin de livrer les Articles et d'atteindre l'Objectif de Sprint.

Dans certaines circonstances, une équipe peut être en avance sur son calendrier et (après avoir éliminé toutes les autres tâches utiles qui pourraient améliorer les capacités de l'équipe) peut décider de travailler avec le Product Owner pour sélectionner une autre histoire (qui aurait déjà dû être priorisée et dimensionnée) à partir de le Product Backlog ... mais seulement s'ils ont la certitude qu'il sera achevé dans ce Sprint et qu'il s'aligne avec l'objectif du Sprint.

Donc, nous l'avons là; OUI ... les équipes ajoutent des tâches au plan Sprint Backlog comme requis. NON, ils ne s'ajoutent généralement pas à la liste des éléments de backlog qui définissent la portée du sprint.

J'espère que cela clarifie la situation.

Cela dépend de vos situations. Si certaines informations sont omises lors de la planification, puis que vous comprenez plus tard que vous devez modifier ou ajouter des points à quelques histoires, je pense que c'est bien. Mais, oui, si la portée d'une fonctionnalité change complètement, c'est une situation extrême et doit être traitée différemment.

Mais bien sûr, pendant la planification, il est supposé que tout le monde connaît clairement et discute de chacune des fonctionnalités sur lesquelles il travaillerait. Si les discussions et la planification sont bonnes, dans presque tous les cas, vous n'avez pas vraiment besoin de modifications.

Je suis d'accord avec les réponses, je voudrais souligner que si l'histoire a commencé son développement, elle ne peut pas être arrêtée tant qu'elle n'est pas terminée.

Creusez les talons dès le début. Ceux qui demandent le changement devront apprendre à la dure, sinon vous finirez par planifier sans valeur si les gens apprennent que vous pouvez quand même faire ce que vous aimez.

Citez que la qualité vient de la concentration et que les bugs viennent de l'abandon d'une pensée. Citez le coût du changement de contexte. Le suivi de la dette et la gestion de la rédaction, de la discussion et de la lecture d'une histoire pour aborder un travail à moitié cuit sont coûteux. Ne commencez pas sur cette voie.

Idée: donner à la direction 3 crédits de substitution à dépenser chaque trimestre en guise de compromis.