Pourquoi utilisons-nous des points d’histoire plutôt que des jours de travail pour estimer les user stories?

Dans les méthodologies agiles (par exemple SCRUM), la complexité / les efforts nécessaires pour les user stories sont mesurés en points d'histoire. Les points d'histoire permettent de calculer le nombre d'histoires utilisateur qu'une équipe peut accepter dans une itération.

Quel est l’avantage d’introduire un concept abstrait (points d’histoire), dans lequel on peut simplement utiliser une mesure concrète, telle que l’homme-jours estimée? Nous pouvons également calculer la vitesse, estimer la couverture d'une itération, etc. en utilisant des jours-hommes estimés.

En revanche, les points de récits sont plus difficiles à utiliser (car le concept est abstrait), mais aussi plus difficiles à expliquer aux parties prenantes. Quel avantage offre-t-il?

Je pense que l'un des principaux avantages est que les humains et les développeurs sont en fait assez mauvais pour estimer le temps. Pensez aussi à la nature du développement - ce n'est pas une progression linéaire du début à la fin. C’est souvent «écris 90% du code en 10 minutes, puis arrache tes cheveux pour 17 heures de débogage». C'est assez difficile à estimer dans le sens du minutage.

Mais utiliser une abstraction élimine le temps réel en heures ou en jours et se concentre plutôt sur la description de la dépense relative et de la complexité d'une tâche par rapport à d'autres tâches. Les humains / développeurs sont meilleurs à cela. Et puis, une fois que vous aurez fredonné avec ces estimations ponctuelles et quelques progrès réels, vous pourrez commencer à regarder le temps plus empiriquement.

Je soupçonne qu’il existe également un effet d’observateur qui se produit avec des estimations de temps qui ne se produirait pas avec des estimations ponctuelles. Par exemple, l'incitation à donner au client une estimation et à la livrer "à l'avance" va être atténuée avec l'indirection dans un système basé sur des points.

Si vous utilisez des nombres de Fibonacci (ou quelque chose de similaire), cela limite le nombre d’options lors de l’estimation d’un récit. J'ai travaillé avec un groupe qui n'utilisait que de faibles nombres: 1, 2, 3, 5, 8 et 13. Nous avions une histoire de référence qui était un 5. Cela nous permettait de prendre facilement des décisions rapides sur la complexité d'une histoire tout en faisant Planning Poker . L’autre effet secondaire était que tout ce qui était noté 13 avait probablement des informations insuffisantes et devait être décomposé plus avant. Je doute sérieusement que cela aurait été aussi simple et facile si nous utilisions des heures brutes.

Votre responsable de produit parle la langue de vos parties prenantes et devrait être en mesure de faire la traduction entre les points de scénario et les heures-personnes (ou d'autres unités) selon les besoins. Au cours de ma carrière en tant que bon de commande, j'avais des données précises selon lesquelles 1 point d'histoire = 4 heures-homme, mais chaque équipe est évidemment différente.

Modifier:

Sachant qu'un point = 4 heures, vous pourriez théoriquement modifier votre deck Planning Poker en 4, 8, 12, 20, 32 et 52. Mais ces chiffres sont plus difficiles à gérer. Je pense que je résumerais mentalement les valeurs en quelque chose de simple, par exemple, "moins d'un jour", "plus d'une semaine", etc. points d'histoire sans

Cela permet d'améliorer les estimations avec le temps, sans que les estimateurs aient tous à ajuster leur estimation.

Au lieu que toutes les personnes impliquées dans l'estimation aient à penser comme "OK ... ça ressemble à 2 jours homme ... mais le dernier sprint, nous avons tout sous-estimé, alors peut-être que c'est vraiment 2,5 jours-hommes. Ou 3?", Ils continuent comme avant. "5 points d'histoire!"

Ensuite, vous ajustez votre estimation du nombre de points d’histoire que l’équipe peut obtenir lors d’un sprint, en fonction des résultats réels mesurés lors des sprints précédents. "Nous avions fait 90-110 points d'histoire par sprint auparavant!"

Je dirais que la théorie derrière cela est que les développeurs sont mieux à même d’estimer la complexité relative de différentes tâches de développement que d’estimer les absolus . Surtout si plusieurs personnes estiment une tâche qui pourrait être effectuée par l'une d'entre elles (et que tout le monde ne travaille pas à la même vitesse que tout le monde).

Alternative cynique: j'ai déjà vu qu'il était dit que les développeurs ne venaient jamais en dessous des estimations de temps. Si quelque chose prend plus de temps que prévu, vous êtes passé au dessus. Mais si quelque chose prend moins de temps que prévu, les développeurs peuvent la manipuler, la plaquer au doré, ou tout simplement ralentir et ralentir et se détendre, puisqu’ils se voient confier une tâche difficile. Prendre les unités de temps réelles dans une estimation peut enrayer ces tendances. Fin de l'alternative cynique.

Les jours-hommes ou les heures-hommes sont, comme vous le dites, concrets. Donc, quand une tâche est estimée à 5 heures et prend 6, c'est maintenant une tâche en retard.

Lorsque vous avez une histoire qui est un 3 points et cela prend 6 heures, cela a pris 6 heures, il n'est pas tard, il a juste pris six heures. La mesure de la vitesse est plus qu'un facteur du nombre de points obtenus lors d'un sprint, et ce nombre peut fluctuer, car il n'est pas concret. Vous ne mesurez pas non plus chaque tâche, mais le total de toutes les tâches. Lorsque vous avez des heures pour chaque tâche, la tentation est là de mesurer chaque tâche. Lorsque cela se produit, vous n’obtenez aucun avantage pour le sprint si vous terminez en deçà du temps imparti. C’est une conséquence pour terminer au fil du temps d’une tâche donnée.

Cela peut être une transition vers une réflexion en termes de points. A un endroit où j'ai travaillé avant même d'introduire des tailles de t-shirts agiles usagés, juste pour avoir une idée du niveau d'effort. Les points ne sont qu'une extension de cela.

Cela ne veut pas dire qu’il n’ya pas de controverse, ni d’assignation arbitraire aux points. Nous avons des membres de notre équipe qui votent presque toujours le nombre le plus bas et se plaignent quand ils pensent qu’une tâche est un 1 et que nous pensons que c’est un 3 qui souffre de l’inflation de points.

L'abstraction est en quelque sorte le but. L’utilisation de la «journée de travail» comme mesure comporte un certain nombre de pièges, notamment:

1. Si l'équipe ne connaît pas bien la technologie qu'elle utilisera, il peut être très difficile de donner une estimation en temps réel de la durée d'une tâche. Ils sont beaucoup plus susceptibles de pouvoir donner de bonnes estimations relatives - par exemple, "la tâche A prendra probablement deux fois plus longtemps que la tâche B".
2. Différentes personnes travaillent à des taux différents! Si vous utilisez "jours ouvrés", vous devez pratiquement changer le temps estimé lorsqu'une tâche est passée d'un développeur à un autre. Qui définit combien de travail constitue de toute façon une journée-homme?

Si vous voulez estimer homme-jours c'est un calcul simple:

user points in story / average user points per developer per day = estimated man days

Comme déjà mentionné, les points de récits sont une mesure relative de la complexité. On peut utiliser une puissance de 2 séries (1,2,4,8,16 ...) ou une échelle de Fibonacci (1,2,3,5,8,13,20 ...) pour l'estimation. En tant que développeurs, ils sont tout à fait habiles à dire quelque chose comme ceci:

La fonctionnalité A est presque deux fois plus dure que la fonctionnalité B

Mais il est vraiment difficile de dire «combien de temps» cette fonctionnalité prendra pour être mise en œuvre. Vous laissez cela être équilibré par la vélocité. Donc, si quelque chose est estimé à 5 mais se révèle être un 13, une vitesse plus lente normaliserait cela pour l'itération (ou vous pourriez ré-estimer).

Maintenant, il y a une autre alternative, ça s'appelle 'des jours idéaux' (certains ressemblent à des hommes-jours mais je ne sais pas si c'est ce que vous vouliez dire) et je connais pas mal d'équipes qui préfèrent ça. Les jours idéaux doivent être interprétés comme:

Si c'est tout ce que je fais après mon arrivée au bureau et que je ne prends que les pauses nécessaires, je ne subis aucune interruption et je disposerai de tout ce dont j'ai besoin pour "mettre en œuvre le récit", c.-à-d.

Mike Cohn, l'un des nombreux évangélistes agiles bien connus, offre la comparaison suivante entre les points d'histoire et les jours idéaux

Points d'histoire

• Permet de générer un comportement interfonctionnel, c'est-à-dire que les équipes évaluent les histoires en fonction de la complexité totale de la mise en œuvre, de l'interface utilisateur à la base de données
• Les estimations de SP ne se détériorent pas, c’est-à-dire que dans quelques mois une histoire à 5 points est toujours susceptible d’être de 5 points, mais une estimation du jour idéal peut changer en fonction de la compétence / vitesse de développement acquise de ce programmeur particulier
• Les SP sont une mesure pure de la taille, c’est-à-dire qu’elles ne reflètent que la complexité de la taille. Période. Aucune durée, etc. C'est le travail de vélocité. Mais pas si avec des jours idéaux. En fait, avec les jours idéaux, on a tendance à le confondre avec les jours calendaires. Le garder abstrait alors que les SP combattent la tentation de se comparer à la réalité. Juste une mesure de taille. Pas de bêtises.
• Est généralement plus rapide que les jours idéaux. Cela peut être délicat pour les deux premières histoires, mais une fois que vous avez compris, c'est plus rapide.
• Différents développeurs peuvent avoir une idée différente de l’évaluation de leur journée idéale pour compléter une histoire. Je pourrais faire la même chose en 3 et vous pouvez en 5. Les PS sont plus ou moins uniformes. Ils nivellent le terrain de jeu pour ainsi dire.

Jours idéaux

• Plus facile à expliquer en dehors de l'équipe; pour des raisons évidentes :)
• Plus facile à estimer au début comme mentionné ci-dessus. Mais une fois que vous maîtrisez les SP, cela vient naturellement

Maintenant, lequel choisir est à l'équipe. Cependant, comme la plupart des réponses ici et mon expérience personnelle, je préfère les points d’histoire. Les journées idéales n'ont pas vraiment d'avantages sur les SP (et Mike Cohn préconise également les SP ainsi que de nombreux autres évangélistes agiles).

Les points d'histoire vous aident également à mesurer l'amélioration des performances de l'équipe au fil du temps. De plus, il n'est pas nécessaire de tout réestimer à mesure que les performances s'améliorent.

Prenons cet exemple qui utilise les jours-hommes:

L'équipe estime différentes tâches en hommes-jours. Cela fonctionne pendant un certain temps, mais après un certain temps, vous constaterez que l’équipe se fait plus rapidement avec de nombreuses tâches que ce qui avait été prévu au départ. L'équipe réévalue donc les tâches. Cela fonctionne pendant un certain temps, et après un certain temps, vous voyez à nouveau la même chose: l’équipe se fait plus rapidement avec de nombreuses tâches. Donc, vous ré-estimez encore, et cette histoire se répète encore, et encore et encore ...

Pourquoi? Parce que les performances de votre équipe ont augmenté. Mais vous ne savez pas à ce sujet.

Le même exemple avec des points d'histoire:

L'équipe estime la taille des user stories. Après quelques sprints, vous voyez que l’équipe peut faire environ 60 points d’histoire par sprint. Plus tard, vous constaterez que l’équipe a atteint plus de 60 points d’histoire, peut-être 70. Et l’équipe continue de la même manière.

Pourquoi? Parce que la performance a augmenté. Et vous pouvez le mesurer. Et vous n'avez pas besoin de tout réestimer une fois que les performances de votre équipe ont augmenté.

Premièrement, les gens sont meilleurs aux estimations relatives qu’aux estimations absolues. La cartographie et l'évaluation de la luminosité relative des étoiles par les babyloniens en sont un excellent exemple. Ils n’ont pas obtenu les chiffres absolus exacts, mais l’ordre était généralement parfait, même pour des intensités très similaires.

Le deuxième avantage est que l’un des principaux objectifs de cet exercice est de stimuler la conversation. Si vous commencez à discuter les jours exacts, la conversation risque de dérailler rapidement.

Comme le disait Napoléon: le plan ne vaut rien, la planification est inestimable.

Troisièmement, le chef de projet n'a pas à éditer toutes les estimations, simplement parce qu'il s'avère que les estimations ont été décalées d'un facteur, par exemple, de 130%.

Les points de récit reflètent la complexité du problème et, par conséquent, la confiance (ou le risque) quant à la précision de l'estimation.

Une histoire avec un point d'histoire élevé me dit qu'il y a beaucoup de choses qui ne sont pas concrètes dans l'histoire de l'utilisateur.

L'idée est de voir quel est le bon équilibre entre les différents points de l'histoire. Si on me présente un plan d'itération avec des histoires avec tous les points forts de l'histoire, cela ne me donne aucune assurance que l'itération sera exécutée comme prévu et que nous devons examiner d'autres histoires pour l'itération ou commencer à décomposer les histoires.

Lorsque vous communiquez avec un responsable ou un responsable de produit, des points d'histoire élevés signifient qu'il sera extrêmement difficile de savoir quand ils obtiendront une fonctionnalité particulière. Une des solutions consiste à décomposer l’histoire et à espérer que vous disposerez d’une combinaison de points d’histoire faibles et élevés afin que vous puissiez démontrer de façon itérative les progrès réalisés au Product Owner.

Les jours-hommes estiment le temps qu'il faut pour faire quelque chose. Ils sont mieux utilisés lorsque les éléments que vous estimez sont très précis et mesurables. Des tâches spécifiques, bien connues et pouvant être répétées sont estimables en nombre de jours-homme.

Par exemple, si un vendeur peut passer 20 appels client par jour, en moyenne, nous pouvons calculer le temps que prend chaque appel et à partir de cela, nous pouvons estimer le nombre de jours-hommes nécessaires pour passer 1000 appels.

Dans cet exemple, on peut penser concrètement en termes statistiques à la longueur médiane d’un appel, car on peut supposer que tous les appels sont effectivement la même chose.

Les points d’histoire déterminent quelle combinaison d’histoires peut être faite dans une itération. Ils sont utilisés pour combiner des objectifs hétérogènes avec des limites floues et pour mesurer combien peuvent être réalisés dans un laps de temps déterminé. Ils estiment la complexité des morceaux de travail les uns par rapport aux autres afin de pouvoir les additionner.

Par exemple, votre équipe a créé 5 histoires pour un total de 23 points en itération 1 et 8 histoires pour 20 points en itération 2. À partir de là, vous pouvez estimer qu’en itération deux, votre équipe fera quelques histoires dont le total est d’environ 20 points. dans l'itération 3.

Notez qu'il n'est pas nécessaire de déterminer la taille d'un point et en particulier, il n'est pas supposé que chaque histoire de la même taille prendra le même temps pour être développée! Nous travaillons uniquement sur des sommes et sur des points par itération. Je n'ai même pas mentionné la longueur de l'itération.

Si vous vous approchez d'un humain dans la rue et demandez "Quelle était la taille d'un T-rex?" les réponses varieraient même si la majorité des humains savent ce qu'est un T-rex, quelle en est sa taille, mais personne ne le sait vraiment - car nous n'avons AUCUNE échelle relative entre nous.

C’est le comportement cognitif que vous essayez de comprendre avec les prévisions et de nombreuses méthodologies qui font tourner les cycles avec " je les ai! .. j'ai le secret pour des prévisions précises! " De l’huile de serpent aux masses. Lorsque vous prévoyez réellement, vous dites vraiment que vous laisserez entendre « Je vais permettre x jours / heures / points pour que cela soit terminé » - c'est en quelque sorte créer une «boîte de temps» pour que l'événement se déroule à l'intérieur.

Pour moi, Points ne fait que déplacer les limites, à la fin de la journée, à moins que vous ne soyez dans une équipe heureuse de dire " * Eh bien, nous avons 3 semaines par sprint et le pouce est nul ... je pense que nous devrions viser Qui est avec moi! * "Et qui est aussi profond que vous allez dans la modélisation des prévisions - bien! ..as réaliste que vous venez de fixer un budget arbitraire et c'est tout. Vous êtes également ensuite en train de regarder rétrospectivement le travail effectué avec le sentiment de "merde sacrée, nous avons lancé 33 points ce sprint, c'était plutôt cool" et rien ne peut être fait à ce sujet. Vous pouvez utiliser la vélocité pour déterminer si votre budget est correct à mi-course en demandant à voix haute " Avons-nous déjà atteint 15 pts? Allons-nous""mais le danger ici est que vous utilisez maintenant Velocity pour mesurer la productivité et non la capacité, ce qui, si j'ai bien compris, donne un coup de fouet à la gestion de la version réactive (Story Points) dans la tête ..

Le système de points est presque trop intelligent pour ne pas remarquer que vous attachez toujours du temps relatif à l'équation, de vos "cycles de sprint" convenus à vos relevés quotidiens dans lesquels vous incarnez une règle cachée autour de la durée + complexité = " Max prend trop de temps avec cette tâche "instinct inné sentiment code rouge moment?

Le cerveau humain ne peut pas prévoir parce qu'il implique beaucoup de mémoire de travail mélangée à un rappel à long / court terme, c'est donc comme demander à un étudiant en mathématiques novice de faire des fractions dans sa tête, pas sur papier. C'est pourquoi les autres industries ne sont jamais d'accord sur une prévision et Validez constamment les prévisions en temps relatif (par exemple, les géologues ne cessent jamais de modéliser les prévisions tant que le mètre cube n’a pas été extrait du sol, puis c’est fait).

Je dirais que le système de points fonctionne si vous ne faites pas de prévisions . Vous acceptez une partie du travail qui repose sur un algorithme de sous-segmentation, mais qui constitue votre approche de prévision la plus proche possible. En fait, votre responsable de la publication chercherait des ruptures naturelles dans la file d’arrière-plan qui correspond à un ou plusieurs thèmes (c’est-à-dire que dans Silverlight, les chefs de produits attendaient qu’ils aient terminé leur arriéré pour reconstituer les thèmes que nous avions initialement définis. Je ne savais jamais ce que l'équipe d'ingénieurs faisait spécifiquement, nous avions juste un aperçu de base. Nous prenions ensuite ce travail et organisions notre événement marketing autour de celui-ci (Microsoft Mix).

Lorsque vous commencez à fixer des prévisions de vélocité à l'intérieur de cycles de sprint qui reposent sur la vélocité + le temps, vous êtes de nouveau en mesure de prévoir des estimations, mais cette fois-ci vous êtes moins bien loti parce que vous jouez au jeu "ça dépend" ... Plus important encore, vous Nous éliminons également le potentiel de croissance d’équipe / de carrière.

La taxe que vous payez pour Points vs Time correspond aux points dont vous avez besoin pour rechercher des formules de mesure alternatives permettant de suivre le développement des compétences en ligne / le mentorat ou le comportement du développeur.

Dans la mesure où vous aurez toujours besoin de rechercher un "développeur médian" comme personne idéale avec laquelle vous souhaitez associer compétences / efforts, vous pouvez ensuite contacter d’autres développeurs avec cette personne pour déterminer dans quelle mesure elle tient compte de sa croissance continue au sein de votre équipe. Il met également en évidence les situations dans lesquelles les développeurs "rapides" transportent la majeure partie de l'eau mais s'ennuient ou empirent, travaillent plus longtemps et ne sont pas reconnus / récompensés en raison d'échéances concurrentes, etc. il détecte les mauvaises odeurs au sein de l'équipe, comme dans "cette personne a des difficultés, aide"

Viennent ensuite les histoires de "report", des histoires qui ne sont pas incluses dans ce cycle de sprint mais qui se propagent ensuite au cycle de sprint suivant. Ce qui peut alors facilement créer un effet d'entraînement si vous prenez en compte le temps, mais dès que vous prenez en compte le temps relatif..en outre, vous venez de revenir à la "prévision / estimation basée sur le temps" et encore une fois, le système de points est juste. brouillant les eaux.

Si vous marquez des points, vous aurez totalement ignoré le temps et je veux dire complètement, au moment où vous laissez le temps s'infiltrer, vous jouez l'idée / la méthodologie.

Ayant voyagé à travers le monde en tant qu'évangéliste, j'ai vu beaucoup d'équipes assermenter tout ce qui leur tient à coeur qu'elles ont déchiffré le code Agile Forecast ... mais j'ai toujours cliqué sur ma langue, souris et suis repartie avec la pensée " ouais ... tu as failli le faire, mais cette maîtresse que nous appelons "le temps" ... elle est juste cruelle ... "

Le livre "Estimation et planification agiles" de Mike Cohn décrit les avantages et les inconvénients de l'estimation avec des "jours idéaux" ou des points d'histoire. La réponse rapide à votre question est qu'il n'est pas nécessaire d'estimer avec des points d'histoire. S'il est plus naturel d'estimer le nombre de jours idéaux, continuez.

Je pense que la méthode Story Point présente au moins deux avantages importants par rapport à la méthode des jours ouvrables: Premièrement, elle est plus facile à estimer dans SP. La SP est relative et les humains comme nous valent mieux que l'estimation absolue comme la méthode du nombre de jours-hommes.

Deuxièmement, lorsque vous estimez en SP, vous obtenez "Team SP" et non pas "Individual Manday". Lorsque vous demandez "Combien de temps cela va prendre?", Le développeur senior peut vous donner 1 jour mais 5 jours pour un junior. C'est le jour de l'homme qui décide qui va s'en charger. Si le propriétaire est forcé de changer (et ce sera le cas!), Vous devez tout planifier à nouveau. Avec SP, c'est toujours le même qui prend la tâche.

Je suis surpris que personne n'ait encore mentionné la loi de Parkinson .

Les travaux se développent de manière à occuper le temps disponible pour les terminer.

Fondamentalement, si vous estimez dans n'importe quel type d'unité de temps pour de grandes tâches, les développeurs auront tendance à prendre le temps estimé pour le terminer ou le dépasser. Lorsque vous estimez en une période nébuleuse comme les points d’histoire ou les tailles de chemise, vous évitez ce piège.

L'estimation du point de l'histoire suit la série de fibonacci 1,2,3,5,8,13,21 ...

Un cerveau humain peut facilement cartographier les choses en fonction de leurs tailles. Par exemple: nous avons une carte postale et lui attribuons un point d'histoire 2 et la taille de trois cartes postales signifierait 2 * 3 = 6 points d'histoire.

Le point de récit 6 se situe entre les séries 5 et 8 de fibonacci, 5 étant le nombre le plus proche et, par conséquent, le point de stockage serait 5.