Chaque jour, après le stand-up , mon équipe et moi mettons à jour nos estimations pour chaque histoire. J'ai le sentiment qu'il y a quelque chose qui ne va pas dans notre façon de procéder, j'ai donc besoin de votre aide.
C'est comme ça qu'on fait:
Story A estimation: 24 heures (8 heures par jour - nous utilisons des "jours idéaux" comme mesure)
- Jour N: le développeur commence à travailler sur l'histoire A le matin (8 heures de travail terminées à la fin de la journée)
- Jour N + 1: réestimation de l'histoire A = 16 heures (une journée de travail hors histoire A, à partir du jour N)
- Jour N + 2: réestimation de l'histoire A = 8 heures (une journée de travail hors histoire A, à partir du jour N + 1)
- Jour N + 3: L'histoire A devrait être terminée maintenant. Mais ce n'est pas. Le développeur estime qu'il faudra encore 3 heures pour terminer. Nous mettons à jour l'histoire sur le tableau blanc et le burndown en conséquence.
- Jour N + 4: L'histoire A a pris toute la journée pour être terminée au lieu de seulement 3 heures! Maintenant c'est fait. La différence, 5 heures, est totalement ignorée dans notre planification.
Comment devrions-nous réévaluer quotidiennement nos histoires?
scrum
estimation
Pomario
la source
la source
Réponses:
Oui, cela est implicitement expliqué car les tâches suivantes sont retardées. S'il y avait un graphique de burndown uniquement pour ce développeur, vous remarqueriez que la courbe est restée "plate" pendant une journée alors qu'elle aurait baissé si le développeur l'avait terminée suffisamment tôt pour entreprendre une autre tâche.
Il n'y a rien de mal à la façon dont vous réestimez pendant la réunion quotidienne, la réestimation consiste plus à déterminer si nous pouvons arriver à la fin du sprint qu'à suivre le retard exact de chaque tâche. Tout ce dont vous avez besoin dans Scrum pour pouvoir ajuster votre plan sur une base quotidienne est quelque chose qui indique la progression de Sprint et à quelle distance vous êtes d'atteindre l'objectif de Sprint (généralement, un graphique de burndown).
la source
La question que vous devriez vous poser est la suivante: devrions-nous réévaluer nos histoires?
Je dirais que vous devriez permettre à la "magie" agile d'équilibrer vos sous-estimations et surestimations sur une itération lors du calcul de votre vitesse pour la prochaine (ce qui est la seule raison de corriger une valeur). Voir Estimation et planification agiles de Mike Cohn pour plus d'informations.
Cependant, il y a un cas où vous devriez réestimer: où quelque chose que vous avez appris sur une catégorie de travail ajuste toutes les estimations à l'avenir.
par exemple. Si l'ajout d'une colonne à une base de données est estimé à prendre une heure idéale, mais il s'avère que cela prend 3 heures en raison d'un facteur que personne n'a pris en compte et il semble que ce facteur s'appliquera chaque fois que vous ajoutez un champ à la base de données alors toutes les estimations pour un travail de cette nature devraient être ajustées, y compris celle sur laquelle vous travaillez.
la source
Ce que j'ai trouvé le plus efficace, c'est:
Si les histoires entrent dans le sprint avec de fausses estimations, les réestimations de planification pré-sprint vous permettront de les corriger avant qu'elles ne deviennent un problème. Si les histoires prennent plus de temps que prévu parce que l'équipe est trop optimiste, la météo d'hier vous gardera sur la bonne voie.
Les réestimations quotidiennes de ce qui reste ont tendance à être totalement fausses, comme vous l'avez décrit dans votre question. Le travail terminé / restant est un faux numéro conçu pour donner l'impression que vous travaillez "assez dur". Il vaut beaucoup mieux demander: «Quand pensez-vous que vous aurez terminé?» Et indiquer clairement que s'il y a un problème avec une histoire, que l'équipe interviendra pour vous aider.
la source
Je pense que ce n'est pas un problème. Il s'agit plutôt d'un manque d'expérience. Plus vous suivez scrum, plus les développeurs s'habituent à fournir des estimations plus précises. C'est notre expérience de mise en œuvre de Scrum après 5 mois.
Lors de la planification des sessions de poker , nos développeurs proposaient des estimations très diverses pour chaque PBI et chaque tâche lors du premier sprint. Cependant, maintenant, nous sommes presque égaux sur le temps et l'estimation. Depuis combien de temps utilisez-vous Scrum? Sinon, donnez-lui un peu de temps. Mais si cela prend du temps, comme l'a suggéré @pdr, envisagez d'ajouter une marge supplémentaire pour les tâches présentant des risques plus élevés . Par exemple, chaque fois que notre équipe souhaite créer un morceau de navigateur croisé d'interface utilisateur, nous passons notre estimation. Ainsi, nous multiplions toujours l'estimation des tâches inter-navigateurs par un facteur pour nous assurer que nous pouvons la couvrir.
la source
Réestimer les user stories engagées pendant le sprint n'a pas de sens. Cela ne fait que perdre votre temps. Vous avez déjà pris un engagement et peu importe si vous faites une réestimation ou non.
La situation est différente avec les user stories qui ne sont pas engagées dans le sprint actuel. De temps en temps, il est bon de faire une réestimation (pas plus d'une fois par sprint avant la planification). Les situations pour lesquelles il peut être raisonnable de réestimer peuvent être:
Vous n'avez pas besoin de réestimer nécessairement chaque user story mais vous pouvez. Pour une réestimation complète, vous avez généralement besoin d'une méthode rapide. Planifier le poker peut être sacrément lent, inefficace, ennuyeux et parfois aussi inexact si vous prenez plus de 10 à 20 histoires à estimer. L'alternative peut être l' estimation magique .
la source