À quelle fréquence une équipe Scrum doit-elle respecter son engagement Sprint? [fermé]

L'engagement est une promesse, et nous avons tous appris que vous devez tenir vos promesses. Mais est-il réaliste de garder l'engagement pour chaque Sprint? Parfois, les gens tombent malades, parfois l'approche technique s'est avérée erronée et vous devez tout repenser, parfois lors de discussions ultérieures avec le propriétaire du produit ou les utilisateurs, vous comprenez que la fonctionnalité devrait être très différente de ce que vous pensiez à l'origine.

Je sais que le Scrum Guide officiel utilise désormais le mot «prévisions» plutôt que «engagement», probablement pour résoudre ces problèmes.

Ma question est donc de savoir à quelle fréquence les équipes de vos organisations respectent-elles leur engagement et si vous aimez cette approche ou si vous voulez la changer.

Je vous remercie.

Ce n'est pas tant une question de savoir à quelle fréquence une équipe doit "tenir ses promesses".
Il s'agit plutôt de rechercher pourquoi une équipe aurait du mal à respecter ses engagements.

S'il s'agit d'une intervention pieuse, cela n'a pas vraiment d'importance. Mais si vous constatez que vous devez fréquemment retourner à la planche à dessin, parce que votre approche technique est tout simplement erronée, ou que le PO change constamment d'avis, ou que les histoires ne sont pas assez claires au début d'un sprint, alors vous besoin d'étudier pourquoi.

Ne pas respecter un engagement de sprint est un symptôme; vous devez vous intéresser à la cause première.

Si tout va bien, alors il sera normal que les équipes respectent leurs engagements de mêlée. Ils devraient être assez cool pour faire face à des perturbations à petite échelle, raisonnables et probables telles qu'une maladie d'un jour, des urgences en matière de garde d'enfants, etc. sans que cela ne déclenche immédiatement et automatiquement un échec à respecter son engagement de sprint. Si cela ne peut pas, à mon avis, les sprints sont trop engagés et courent trop chaud pour leur bien à long terme en équipe.

Si les sprints ne parviennent toujours pas à livrer, la mêlée a tenu sa promesse de rendre les «problèmes» visibles. Les problèmes peuvent inclure le fait de ne pas avoir de tâches correctement définies, une expérience insuffisante dans l'équipe ou une culture de gestion consistant à essayer continuellement de sur-livrer - et donc à manquer constamment.

Dans les deux cas, la solution consiste à identifier la cause première et à la corriger, plutôt que de fouetter plus durement les développeurs.

Des équipes toujours «proches» de leurs engagements échouent de manière plus sérieuse. Vous pouvez être sûr qu'ils n'effectuent pas suffisamment de tests.

Je crois personnellement que si personne dans l'organisation ne se soucie de respecter votre engagement, vous ne parlez pas d'un engagement. Vous avez besoin de deux partenaires pour conclure un accord et former un engagement.

Un engagement de sprint est quelque chose que vous devriez pouvoir tenir, en tenant compte de toutes les "variations normales". Vous pouvez lire mon article de blog sur les bases de la planification agile si vous voulez en savoir plus sur ce que je veux dire par variation de base. Et comme Stefan l'a déclaré , ne pas respecter votre engagement est un symptôme et non la maladie.

Après chaque sprint, vous avez un moment pour inspecter la vitesse réelle de ce sprint et adapter votre "vitesse moyenne" à celle-ci (comme expliqué dans le post mentionné ci-dessus ). Si votre vitesse continue de baisser, sprint après sprint, vous commencez à voir des modèles qui peuvent vous aider à détecter la véritable cause première de cela. Cela pourrait être trop de travail imprévu (par exemple, de petites tâches urgentes à venir, des bugs dans le code sur lequel vous travaillez, des modifications des critères d'acceptation pendant le sprint, ...). Toutes ces données doivent être suivies, très probablement par le Scrum Master pour l'aider à comprendre quels modèles sont là. Cela aidera l'équipe à trouver des actions lors de la rétrospective.

Mon point de vue est que les équipes ne s'engagent pas. Sans doute, ils ne font même pas de prévisions. La prévision est faite avant la planification du sprint - la prévision est qu'en moyenne, ils atteindront leur vitesse. Cela signifie que parfois ils feront quelques points de plus que leur vitesse, parfois ils feront un peu moins.

Si vous faites régulièrement moins que votre vitesse, votre vitesse baisse pour refléter cela. La prévision baisse donc également. Si vous continuez à tirer plus d'histoires que votre vélocité historique ne dit que vous pouvez faire sprint après sprint, ce n'est pas un échec dans l'exécution, c'est un échec dans la planification. Vous connaissez votre vitesse, vous ne devriez donc pas rapporter plus de points que l'histoire ne vous le permet.

Pour répondre à votre question spécifique, sur les trois organisations dans lesquelles j'ai utilisé Scrum, une seule a suivi les mesures "manquer la validation" au fil du temps. Pour cette entreprise, les équipes atteignent généralement leurs prévisions dans environ 85% des cas.

Si vous ne respectez pas votre engagement, vous devez réduire votre vitesse. Si vous le rencontrez toujours, vous devez augmenter jusqu'à ce que vous échouiez parfois.

Le problème est à quel point échouez-vous? Il doit toujours être proche. Soit vous le faites avec un peu de mou, soit vous échouez un petit peu. C'est un objectif sain pour n'importe quelle discipline, temps de course, haltérophilie, etc. Idéalement, la quantité moyenne de travail effectuée dans un sprint devrait être une distribution normale autour de votre vitesse.

Ce qui est plus important, c'est la tendance à long terme de votre vitesse. Si chaque semaine vous ajoutez 15 points d'histoire à votre vitesse mais que vous n'en accomplissez que 10 de plus que la semaine précédente, est-ce vraiment une mauvaise chose? À certains endroits, ils considèrent ces «objectifs extrêmes».