Quelle est la meilleure façon d'estimer des points d'histoire dans la mêlée?

J'aime la façon dont la planification du poker fonctionne au début de tout projet, vous permettant de comparer et de discuter les détails de chaque histoire les uns avec les autres.

L'un des problèmes que j'ai remarqués avec cela est qu'avec le temps et que vous acquérez plus d'expérience avec le domaine problématique, vous avez tendance à voter moins de points pour chaque histoire, c'est-à-dire une histoire qui valait 5 ou 8 au début du projet pourrait maintenant valoir 3.

Comment éviter ou résoudre ce problème de la meilleure façon possible? Y a-t-il une meilleure façon d'estimer? Les histoires devraient-elles toujours rester les mêmes, ou ces points d'histoire diminuent-ils bien?

Je ne pense pas que ce soit un gros problème.

Il y a deux choses évidentes qui pourraient être à l'origine de cela. La première est que vous rencontrez une légère déflation ponctuelle. L'autre est que votre équipe devient en fait plus rapide. (J'espère que c'est ce dernier!)

De toute façon, cela ne devrait pas être un gros problème. Les deux utilisations principales de la vélocité consistent à déterminer la quantité de travail à effectuer lors de la prochaine itération et à faire des estimations approximatives des dates de livraison pour de plus gros morceaux de travail. Aucun de ceux-ci n'est affecté par une vitesse qui change progressivement. En effet, si l'amélioration de la vitesse vient de l'amélioration, vos nouveaux chiffres présentent une image plus vraie de la capacité de l'équipe.

Si la vitesse change trop rapidement pour le confort, alors une réponse est des histoires canoniques. Parcourez les deux derniers mois en choisissant 3 histoires chacune pour représenter les niveaux de points que vous utilisez. Mettez-les sur le mur où vous faites des estimations. Ensuite, pendant que vous estimez, utilisez-les comme comparaison avec l'histoire que vous traitez. Cela devrait réduire à la fois la dérive et la volatilité de vos estimations.

Fondamentalement, ce n'est pas vraiment un gros problème, car la plupart de ces choses sortiront au lavage. Dans l'ensemble, la manipulation explicite de la sortie des estimations va être négative pour le processus. L'estimation des points d'histoire fonctionne mieux lorsque les équipes gardent les yeux sur le ballon - vous estimez la complexité relative des histoires par rapport aux autres histoires, et tant que vous avez des informations historiques à portée de main pour les histoires terminées, vous allez probablement voir les choses s'arranger. à long terme. Voici un endroit où la cohésion de l'équipe paie des avantages, car une équipe finira par s'installer sur des méthodes et des histoires de référence pour l'estimation de l'histoire.

La déflation des points d'histoire peut être un problème léger, cependant, dans la mesure où votre gamme d'estimations de points est compressée, vous commencez à perdre des informations sur le réglage fin de la vitesse, et cette compression peut avoir des effets négatifs sur l'estimation de la durée de livraison d'une version à plus long terme planification (dans la mesure où vous allez multiplier les erreurs introduites par la compression de toutes vos histoires dans une plage étroite). Dans l'ensemble, vous voulez que les résultats d'une augmentation de la vitesse due à l'expertise s'expriment comme prenant plus de points d'histoire plutôt que des estimations en baisse. La façon de lutter contre cela consiste à référencer continuellement les estimations précédentes terminées et à vous assurer que vous estimez toujours la complexité. N'indiquez jamais combien de temps vous pensez que quelque chose va prendre, comparez simplement la difficulté globale d'une histoire par rapport aux histoires précédentes. Laisser' s dire que vous avez une application qui prend en charge les plates-formes mobiles et que vous devez porter sur une autre. Est-il similaire à un port précédent? Plus difficile, car la plate-forme a un outillage pire Plus facile, parce que vous avez un meilleur débogueur? Cela devrait informer vos estimations, pas le fait que ce port ira probablement plus vite car vos équipes obtiennent de bonnes estimations. La concentration sur la complexité devrait aider à résoudre ce problème, dans la mesure où il y en a un.