Est-il correct de modifier les estimations au milieu d'une itération?

Nous avons commencé à utiliser Agile / Scrum dans une équipe de 4 développeurs. Nous avons fait nos estimations d'histoires et commandé les histoires Histoires apprêtées dans le backlog de produit.

Nous avons commencé avec l'estimation ponctuelle sur la complexité de 1 à 5, au lieu des 1,2,3,5,8,13 habituels .... et ainsi de suite

Après avoir travaillé sur quelques histoires, nous avons estimé que certaines des histoires qui étaient estimées à 4 points ne devraient être que 2 tandis que les autres qui étaient estimées à 2 sont beaucoup plus complexes et auraient dû être estimées à 5. Je voudrais savoir:

Est-il correct de modifier nos estimations d'histoires au milieu de l'itération?
Est-il correct d'utiliser les points d'estimation actuels de 1 à 5, au lieu des 1,2,3,5,8,13 habituels .... et ainsi de suite

Bien que je pense personnellement que cela ne devrait pas être le cas pour les deux cas, mais je dois me soutenir car ma propre compréhension n'est pas très claire (tout bon matériel de référence serait bien cependant!)

project-management agile estimation

— tintin
source

Demandez-vous: quel est l'avantage de passer du temps à réestimer le sprint en milieu de parcours? Quel est l'avantage de passer plus de temps à «argumenter» par rapport à 3 vs 4 vs 5 à grain fin par rapport à un 3 vs 5 brut?

— Hugo

Réponses:

Est-il correct de modifier nos estimations d'histoires au milieu de l'itération?

Absolument pas. Nous nous attendons à ce que cela se produise. Et nous nous attendons à ce que les erreurs s'équilibrent au fil du temps. Nous ajustons vraiment les estimations uniquement lorsqu'il est clair qu'une certaine catégorie (par exemple de nouvelles pages Web) sera toujours plus complexe que nous ne le pensions lorsque nous les avons toutes estimées.

Comme une histoire épique est décomposée en plus petites histoires (qui devraient se produire bien avant le sprint), nous pouvons sembler ajuster l'estimation originale, mais je l'appellerais affiner plutôt que réestimer. C'est parce que nous avons une vision plus claire à ce moment-là.

Agile Estimating and Planning de Mike Cohn est un bon livre sur le sujet. Je vous déconseille de l'utiliser (ou de tout livre "Agile") comme une bible, mais c'est un bon point de départ pour affiner votre processus.

Il parle de la façon dont les estimations erronées s'équilibrent en tant que «magie», mais souligne qu'il l'a vu fonctionner encore et encore et encore.

Est-il correct d'utiliser les points d'estimation actuels de 1 à 5, au lieu des 1,2,3,5,8,13 habituels .... et ainsi de suite

L'utilisation de la série d'estimations de points de Fibonacci est une acceptation selon laquelle plus une histoire est grande, moins notre estimation est précise (voir mon commentaire précédent sur Epics).

Mais si cela ne fonctionne pas pour vous, surtout si vous gardez tous vos petits travaux, alors ne l'utilisez pas. C'est une ligne directrice, pas une règle.

Le dimensionnement des t-shirts (SML XL XXL) est également populaire et ne diffère pratiquement pas de (1 2 3 4 5).

— pdr
source

+1: Discutez-en lors de votre rétrospective. Réestimez lorsque vous redéfinissez vos priorités au début du printemps prochain. Voilà pourquoi vous avez des sprints. Pas de frais généraux de gestion pendant le sprint - faites simplement du code.

— S.Lott

À propos de l'utilisation de la série fabonacci, disons que vous savez qu'une histoire va prendre près de 3 jours et non. des tâches pour faire l'histoire sont A, B, C. Vous sentez également que ce n'est pas très complexe mais chacune de ces tâches va prendre 1 jour chacune. Quelle estimation donneriez-vous à l'histoire?

— tintin

@tintin: La raison d'utiliser des points est d'éviter de dire des choses comme "vous savez qu'une histoire va prendre près de 3 jours". Les points sont relativement arbitraires, chaque travail est basé sur la complexité par rapport aux autres travaux (vous devez évidemment éviter d'utiliser des travaux mal estimés comme références). Mais, vous évitez les chiffres manquants, pour tenir compte de l'incertitude. Donc, si le travail B est deux fois plus complexe que le travail A et que le travail A a été marqué comme 2 points, vous marquez le travail B comme 5 points.

— pdr

+1 pour: plus une histoire est grande, moins notre estimation est

— précise

Est-il correct de modifier nos estimations d'histoires au milieu de l'itération?

Absolument oui - si cela affectera la planification actuelle ou future du printemps. Le point de l'agilité est de baser vos actions sur des informations aussi actuelles et correctes que possible.

Si une estimation s'avère si fausse que le sprint actuel ne peut pas être terminé dans sa boîte de temps, vous devez agir sur l'estimation révisée, vous voudrez probablement la changer. Si vous basez de nouvelles estimations sur les anciennes (et que vous les examinez plutôt que de vous fier à la mémoire / à l'expérience), vous avez besoin qu'elles soient correctes.

En revanche, il n'y a pas vraiment de valeur en soi dans une estimation correcte. Ne perdez pas de temps à faire des statistiques inutiles.

— Michael Borgwardt
source

Dans notre cas, l'estimation initiale était importante et le travail pour cela s'est avéré bien moindre. Ce n'est donc pas que notre sprint actuel n'est pas terminé à temps, mais nous avons du temps supplémentaire. Le gestionnaire propose donc de baisser l'estimation.

— tintin

@Michael, cette réponse peut être vraie pour certains processus agiles mais la question concerne Scrum. Dans Scrum, il n'est pas recommandé de modifier les points d'histoire après la planification du sprint car la métrique de vitesse de l'équipe pourrait être compromise.

— GuyR

Les estimations échouées présentent un avantage dans la mesure où vous pouvez les utiliser pour ajuster les estimations futures en conséquence. Si vous estimez trop long, c'est autant un échec que d'estimer trop court, car le résultat est des ressources sous-utilisées. La valeur des estimations correctes est que vous savez que vous atteindrez probablement vos objectifs de publication et que votre équipe est pleinement utilisée. Par conséquent, vous basez toujours les estimations futures sur vos expériences passées, en ajustant en fonction de ce que vous apprenez sur vos estimations en cours de route.

— S.Robins