Confus de modifier le backlog de sprint pendant un sprint

14

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.

Maltiriel
la source

Réponses:

10

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.

Martin York
la source
Que feriez-vous s'il y avait simplement un malentendu, par exemple l'équipe pensait qu'un article signifiait une chose tandis que le propriétaire du produit signifiait autre chose, en supposant que les articles étaient de taille à peu près équivalente? Cela s'est déjà produit dans mon travail auparavant, ce n'est donc pas une question purement théorique ...
Maltiriel
3
Pour ajouter à ce que Loki a répondu; vous devriez discuter avec votre Product Owner de toute modification apportée au backlog de Sprint, car l'équipe s'est engagée auprès du PO pour le travail à livrer. Et si une histoire a été mal comprise, alors l'histoire peut être modifiée pour mieux décrire le problème et la valeur commerciale et même être redimensionnée si suffisamment changée. Mais toujours en discuter avec le propriétaire du produit.
David 'le chauve gingembre'
10

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.

BF Clark
la source
1
Hmm, cela aide, en particulier votre point de vue sur les gens qui ne sont pas clairs sur les histoires / articles par rapport aux tâches. Cependant, je me demandais non seulement d'ajouter de nouvelles tâches, mais aussi de les changer / les remplacer, comme en cas de malentendu entre l'équipe et le propriétaire du produit. Je n'ai jamais pu dire quelle est la "meilleure pratique" pour cela, donc si vous avez des commentaires à ce sujet, ce serait apprécié.
Maltiriel
2

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.

Kumar Bibek
la source
"au cours de la planification, on suppose que tout le monde connaît et discute clairement de chacune des fonctionnalités sur lesquelles il travaillerait" Ce sont ces cas que je me pose des questions, car tant de gens semblent si catégoriques que l'arriéré de sprint ne peut en aucun cas être modifié pendant un sprint.
Maltiriel
:) Oui, nous sommes des humains. Et parfois, vous devrez apporter des modifications lors d'un sprint. Mais si cela continue encore et encore, il y a quelque chose de mal ailleurs. Essayez peut-être d'en parler à tout le monde, puis de trouver une solution mutuellement convenue.
Kumar Bibek
0

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.

Luke Puplett
la source
"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 avant d'avoir été terminée." - ce n'est pas vrai. Une équipe peut décider de ne pas terminer un élément d'histoire. Une fois que la planification du sprint pour le prochain sprint a commencé, rien ne les oblige à tirer cette histoire dans le prochain sprint. Cependant, j'aime vraiment cette affirmation: "la qualité vient de la concentration et les bugs viennent de l'abandon d'une pensée"
Bryan Oakley