En mêlée, changez-vous les critères d'acceptation lors d'un sprint?

Question

Mon organisation met actuellement en œuvre Scrum. En travaillant sur un élément de backlog produit pour modifier la façon dont une logique métier est traitée, nous avons réalisé qu'une partie de la logique métier était erronée. L'IBP et ses critères d'acceptation sont actuellement orientés vers la modification de la mise en œuvre de la logique métier existante. Le PO estime que cette modification de la logique métier est une priorité et devrait être intégrée au sprint, et l'équipe de développement est d'accord, d'autant plus que cela aurait beaucoup de sens de faire les deux choses ensemble, du point de vue du développement.

Nous ne sommes pas sûrs, cependant, s'il serait plus logique de modifier les critères d'acceptation ou de créer un nouveau PBI et de le tirer tout de suite dans le sprint. Personnellement, je penche pour un nouveau PBI parce que je pense que c'est une histoire distincte et un ensemble de critères d'acceptation de l'IBP original, et je suis sceptique quant à la modification des critères d'acceptation au milieu du sprint en général. L'OP a fait remarquer que cette nouvelle exigence et l'IBP originale seront mises en œuvre en même temps, et que l'IBP original ne sert à rien sans les nouvelles exigences à satisfaire. L'OP estime donc qu'il serait plus approprié d'ajuster les critères d'acceptation du PBI original au lieu de créer deux critères distincts qui reflètent la même mise en œuvre à la fin.

L'une de ces approches est-elle plus appropriée que l'autre?

Answer 1

Généralement, changer AC pour un ticket (PBI) est un gros non non une fois qu'un ticket a été estimé, en particulier dans un sprint. Cela dit, vous devez vous demander quels problèmes cela peut causer. Le fait de changer le courant alternatif pourrait faire en sorte que l'estimation soit incorrecte, c'est-à-dire trop faible. Et alors? Eh bien, cela pourrait empêcher l'équipe de compléter les tickets engagés du sprint. C'est mauvais.

Un nouveau ticket dans ce cas est probablement une mauvaise idée car cela ne semble pas correspondre au critère "indépendant" d'une histoire INVEST.

La modification du ticket actuel peut entraîner des problèmes de comptabilité lorsque vous essayez de suivre les histoires/points ajoutés pour le sprint, mais à part cela, je ne vois aucun problème. La clé ici est de ré-estimer afin que tout le monde comprenne que c'est plus de travail. Essayez de ne pas vous embourber dans ce qui est «approprié pour la mêlée». Pensez à ce qui fonctionne, à quels problèmes différents vous causeraient et prenez votre décision en fonction de cela. Enfin, assurez-vous que ce problème survient dans la rétrospective afin que vous puissiez discuter des raisons pour lesquelles l'AC était incorrecte ou incomplète dans ce cas et voir si l'équipe peut prendre des mesures concrètes pour empêcher que cela se produise à l'avenir.

PS vous pouvez trouver plus d'aide avec des questions comme celle-ci sur au pm.stackexchange.com

Answer 2

Vous devez modifier des histoires uniquement avec l'accord de l'équipe, parce qu'ils sont engagés à fournir un ensemble de critères. Si vous modifiez les critères sans le consentement unanime de l'équipe, alors pourquoi prenez-vous la peine de l'avoir en premier lieu?

C'est une grosse affaire de vibrer avec le backlog de sprint, parce que vous dévaluez alors l'engagement de l'équipe à livrer un ensemble particulier d'histoires pendant le sprint.

Si l'équipe n'est pas disposée à accepter les changements, l'OP peut retirer l'histoire originale et mettre une nouvelle histoire en haut de l'arriéré. Il pourrait être inclus dans le sprint actuel, ou il pourrait ne pas l'être.Résistez avec chaque fibre de votre idée que le PO peut jouer avec le backlog de sprint pendant le sprint. Mon PO a essayé d'abandonner une histoire vraiment minuscule (basée sur un raisonnement très bidon) vers la fin d'un sprint récent.

De http://www.scrum.org/scrum-guides/:

Seule l'équipe de développement peut changer de Sprint Carnet de commandes au cours d'une Sprint.

Je pense que c'est un bon conseil, et vous ne devriez pas en tenir compte avec une grande inquiétude.

Answer 3

Il existe quelques différences subtiles à comprendre avec Scrum.

Dans Sprint Planning, le propriétaire du produit attribue les exigences les plus élevées suivantes à l'équipe qu'il souhaite obtenir en fonction de la vélocité des équipes. L'OP explique les exigences et l'équipe questionne l'OP sur les détails.

Note: Cela ne devrait pas être la première fois que l'équipe voit l'exigence comme elle aurait dû le voir auparavant dans les sessions de toilettage.

L'équipe discute de son approche, fait ses conceptions et crée un tas de tâches à faire et accepte les prévisions. L'équipe produit un arriéré de sprint, un objectif de sprint et commence à travailler. Personne ne peut modifier l'exigence de base sur laquelle l'équipe travaille; pas même l'équipe. Seul le PO a le droit de mettre fin au travail s'il ne voit pas la valeur de continuer avec lui. Il y a une ligne fine entre une mauvaise planification du côté de l'OP et une clarification de l'exigence.

L'exigence n'est pas un contrat, et l'équipe devrait avoir le noyau juste à ce qui doit être fait. Les détails doivent être rassemblés et modifiés légèrement pour que l'exigence soit satisfaite. L'équipe peut entièrement modifier les tâches sur lesquelles elle travaille, ajouter d'autres tâches ou supprimer des tâches pour faciliter la communication et la collaboration. il suffit de fournir l'exigence requise. La clarification des détails est totalement acceptable.

Le défi de la plupart des équipes est celui de la clarification, qui change la signification de l'exigence. Lorsque cela se produit, vous devez étouffer le problème dans l'œuf dans une rétrospective et adapter à la façon dont vous écrivez les exigences; supprimant ainsi l'ambiguïté. Cela signifie simplement que vous devez passer plus de temps à vous toiletter.

Pour répondre à votre question. S'il vous plaît, si le PO et l'équipe pensent qu'il est logique de modifier quelque chose ... faites-le. Cependant, cela devrait être plus l'exception que la règle. Si cela se produit tout le temps; votre toilettage est mauvais. Il n'y a rien de mal à clarifier les critères d'acceptation et à améliorer la qualité de Sprint.

Answer 4

J'ai très rapidement répondu à votre question. Voici la chose. Nous avons eu une situation similaire. Nous avons créé une histoire de delta et tiré des choses du sprint actuel et l'avons déplacé à un autre sprint. Il suffit de l'appeler DELTA US et donner la version 1.1.

Cela aide-t-il?

Merci, Kris.

Answer 5

Dans cette situation, nous laissons normalement le Product Owner supprimer l'historique utilisateur original du sprint, ce qui libère du temps dans le sprint.Avec ce temps libre, le PO peut demander que la nouvelle histoire utilisateur (avec des critères d'acceptation mis à jour) soit incluse dans le sprint. Il est bien entendu que l'histoire du nouvel utilisateur peut être complétée dans le temps restant du sprint. En divisant le processus en 2 étapes distinctes, il assure que le PO comprend qu'un travail doit sortir d'un sprint avant que d'autres ne puissent entrer, ce qui rend le processus résistant au fluage futur.