Comment mesurer une estimation et des points d'histoire dans Scrum? [fermé]

Question

Prenons un exemple, supposons que nous ayons 5 histoires A, B et C, D, E.

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D 

Les histoires sont classées en fonction de leur importance (priorité). Comment les estimez-vous? Est-ce estimé en fonction de la taille de la fonctionnalité? Par exemple, je leur ai donné des valeurs estimées:

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

Supposons qu'il s'agisse d'un sprint de 2 semaines. C'est la taille de l'heure 14days = 5,14x5 = 70 jours / homme. Maintenant, que signifie la valeur 10? Est-ce que cela signifie une quantité de temps (heures ou jours) qu'une équipe devrait passer? Et quels sont les points d'histoire? Supposons que ceci soit le premier sprint; comment allez-vous estimer le nombre de sprints quand vous n'avez pas la vitesse du dernier sprint?

Answer 1

Argh! Me sert bien pour écrire de la mémoire.

Un point d’histoire est lié à l’estimation, bien entendu, et lorsque vous essayez de déterminer tout ce que vous pouvez faire pour un sprint, il constitue une unité de "travail". nécessaire pour mettre en œuvre une partie ou une fonctionnalité entière. Un point d'histoire pourrait être un jour, une heure ou quelque chose entre les deux. J'ai confondu l '"estimation". et "point de l'histoire" ci-dessous, je ne sais pas ce que je pensais.

Ce que j’avais écrit à l’origine était "estimations". et "points de l'histoire". Ce que je voulais écrire (et édité ci-dessous) était "points d'histoire". et "vitesse".

Les points d’histoire et la vélocité vont de pair, et ils travaillent ensemble pour essayer de vous donner une idée de ce que nous pouvons accomplir au cours d’une période donnée.

Prenons un exemple.

Supposons que vous souhaitiez estimer les fonctionnalités en heures. Ainsi, une fonctionnalité qui a une estimation de 4 prendra 4 heures à compléter, par une personne, et vous affectez une telle estimation à toutes les fonctionnalités. Vous considérez donc que cette caractéristique, ou son "récit", vaut 4 points lorsqu'il s'agit de concurrencer des ressources.

Maintenant, supposons également que votre projet compte 4 personnes travaillant chacune une semaine normale de 40 heures, mais qu'en raison d'autres facteurs, comme le support, les discussions avec le marketing, les réunions, etc., chaque personne ne être capable de travailler à 75% sur les fonctionnalités réelles, les 25% restants seront utilisés pour les autres tâches.

Chaque personne dispose donc de 30 heures par semaine, ce qui vous donne 30 * 4 = 120 heures au total pour la semaine où vous comptez les 4 personnes.

Maintenant, disons aussi que vous essayez de créer un sprint de 3 semaines, ce qui signifie que vous avez 3 * 120 heures de travail que vous pouvez terminer. C’est votre vitesse, votre vitesse de déplacement, le nombre de "points d’histoire". vous pouvez compléter.

L'unité de votre vélocité doit être compatible avec l'unité de vos points d'histoire. Vous ne pouvez pas mesurer les récits dans "Combien de gobelets le développeur consomme-t-il lors de la mise en œuvre de cette " avec "combien d'heures disposons-nous".

Vous essayez ensuite de trouver un ensemble de fonctionnalités qui, ensemble, prend près de 120 points, sans toutefois les dépasser, classés par ordre de priorité. Il s’agirait simplement de faire la somme cumulée du haut et du bas jusqu’à ce que vous obteniez une tâche qui bascule la somme ou égale à ces 120 points. Si cela se produit, n'incluez pas la tâche.

Vous pouvez tout aussi facilement estimer le nombre de jours ou de tasses de café consommés par le développeur, tout comme le nombre est représentatif du type de travail que vous effectuez, et il peut être lié au travail que vous effectuerez ( c’est-à-dire combien de temps il vous reste).

Vous devez également évaluer votre charge de travail après chaque sprint pour déterminer si ce nombre à 75% est exact. Par exemple, si vous ne gérez que la moitié de ce que vous avez décidé de faire, déterminez si votre estimation de fonctionnalité était erronée ou si votre estimation de charge de travail était erronée. Puis, tenez compte de ce que vous avez appris lors de l’estimation et de la planification des sprints suivants.

Notez également que les fonctionnalités doivent être divisées si elles deviennent trop grandes. La principale raison à cela est que les estimations les plus grosses comportent beaucoup plus d'incertitude, et vous pouvez l'atténuer en la scindant en sous-entités et en les estimant. La grande caractéristique globale devient alors la somme de toutes les sous-caractéristiques. Cela pourrait également vous donner la possibilité de scinder la fonctionnalité en plusieurs personnes, en attribuant différentes sous-fonctionnalités à différentes personnes.

Une bonne règle est que les fonctions qui ont une estimation sur 1 jour devraient probablement être fractionnées. *

Answer 2

N'oubliez pas que les points ne sont que des ROM (ordre de grandeur approximatif) établies à l'aide de " Planning Poker " comme une pratique courante. Les premiers sprints ont lieu lorsque vous commencez à identifier la signification des points pour l’équipe. Plus vous avancez, plus l’équipe gagne en précision.

De plus, utilisez des points un peu plus espacés. Une pratique que j’ai vue et utilisée consiste à utiliser la séquence fibonacci , elle s'assure que vous ne pas trop de différences de 1 point.

N'oubliez pas non plus les testeurs: quand on raconte une histoire, les tests doivent être pris en compte, car une tâche de développement simple peut parfois entraîner de gros efforts de test. S'ils sont vrais, le principe est de tout avoir comme prévu. expédié (construit, testé et documenté). L’évaluation d’une histoire est donc déterminée par l’équipe et non par un individu.

Answer 3

La valeur 10 est simplement une valeur relative aux autres estimations, par ex. c'est moitié moins dur qu'un 20 ou un peu plus difficile qu'un 9. Il n'y a pas de traduction spécifique de 1 point = x heures d'effort est quelque chose à souligner.

Là où je travaille, nous avons ce que nous appelons les "points épiques". ce qui est difficile comment est une histoire de haut niveau, par exemple. Intégrez la recherche dans un nouveau site Web, composé de plusieurs histoires à compléter, puis nous estimons le nombre d'heures de chaque histoire créée à partir de la décomposition de chaque épopée, par exemple. il suffit de mettre en recherche des documents de support sur le site. Les "points épiques" sont répartis dans une variation des nombres de Fibonacci (1,2,3,5,8,13,21,28,35), de sorte que des épopées plus larges et plus vagues obtiennent simplement une valeur élevée, par ex. tout ce qui est supérieur à 8 est un indicateur qu'il peut être décomposé en histoires plus faciles à estimer. Il convient également de noter ici que là où je travaille, nous ne travaillons que 5 jours par semaine et lors de chaque sprint, chaque journée est perdue au profit de réunions telles que la démonstration, la réunion de planification des itérations, la rétrospective et la révision, de sorte qu’il ne reste que 9 jours. Ajouter de la programmation en binôme pour certaines choses, du temps pour réparer les bogues et d’autres tâches non liées à un projet fonctionne comme des tickets d’assistance, et il devient plutôt difficile de dire combien d’heures seront consacrées à la poignée de développeurs du sprint.

Les premiers sprints sont ceux où les valeurs commencent à devenir plus concrètes car, en se basant sur l'expérience acquise, les estimations peuvent devenir plus claires pour deviner la valeur.

Answer 4

Avec une nouvelle équipe ou un nouveau projet, nous commençons toujours par supposer que le point d’histoire est une seule "journée idéale" et nous supposons que chaque développeur gagne environ 3,5 jours idéaux par semaine, ce qui nous permet de calculer notre vitesse initiale probable.

Une fois que vous avez traversé le "planning poker" Si vous mettez en scène et comparez toutes vos histoires, la durée réelle d'un point d'histoire est vraiment inconnue - tout ce que vous avez réellement est une assez bonne idée de la durée relative , et utilisez votre meilleur jugement à venir. avec une vitesse probable.

Au moins, c'est comme ça que je le fais!

Si vous souhaitez également que vos points d’histoire soient à peu près égaux à une journée idéale, je vous suggère alors de les décomposer en histoires plus petites, sinon vous ne passerez pas un bon moment à planifier et à suivre des itérations.

Answer 5

De bonnes réponses tout autour.

Un point que je voudrais ajouter est que le choix de la base de votre valeur en points n’est pas vraiment important (heures, jours idéaux, quoi que ce soit d'autre). L’important est de garder la cohérence.

Si vous conservez cette cohérence, cela vous permettra de découvrir la "vélocité réelle". de votre équipe. Par exemple, disons que vous avez eu peu d'itérations:

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

Et maintenant vous commencez l'itération 4 et vous avez les éléments suivants dans le backlog (triés par priorité):

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

En supposant que vos estimations de points concordent, vous pouvez être raisonnablement sûr que l’équipe terminera les points 1,2 et probablement 3 mais certainement pas 4.

Vous pouvez appliquer la même chose à la libération de l'arriéré afin d'améliorer votre prévision de la date de publication. C’est ce qui permet aux équipes Scrum d’améliorer leurs estimations au fur et à mesure.

Answer 6

JB King a la meilleure réponse, mais pas de vote, ce qui signifie que des informations incorrectes sont propagées, ce qui contribue à l'interprétation généralement médiocre de Scrum. Veuillez consulter les vraies réponses de l’une des personnes qui ont conçu Scrum ici:

http: //blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

N'oubliez pas qu'il s'agit d'effort et non de complexité.

Lisez maintenant et regardez une vidéo ici:

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Storing_Points