Estimation du temps pour une user story

Question

Comment estimez-vous le temps nécessaire pour mettre en œuvre une user story? Si c'est quelque chose que vous avez fait avant de savoir combien de temps cela va prendre. Mais qu'en est-il si c'est complètement nouveau pour vous? Combien de temps réservez-vous pour les "surprises"?

Answer 1

Une bonne technique consiste à décomposer l’histoire en tâches plus petites et à les estimer comparées les unes aux autres (au lieu d’absolument). Donc, vous pouvez dire:

• La tâche A prendra 2 unités (arbitraire)
• La tâche B est environ 2 fois plus compliquée que la tâche A (4 unités)
• La tâche C est compliquée à peu près à la moitié (1 unité)

Nous sommes plus aptes à estimer la complexité relative que la complexité absolue. Ensuite, vous effectuez l’une des tâches et déterminez combien de temps "en temps réel" il vous faut 1 unité - vous pouvez maintenant calculer toutes les tâches. Vous continuez de mettre à jour vos estimations en fonction de vos progrès.

Cette technique provient de Estimation et planification agiles de Mike Cohn, qui est un excellent livre sur le sujet.

Answer 2

À l’école de développement agile XP, ils préconisent de ne pas estimer en temps réel mais en unités arbitraires. (Ils utilisent "Gummy Bears" mais vous pouvez utiliser n'importe quoi). Vous déterminez au mieux le nombre d'unités nécessaires à la mise en œuvre de cette user story.

Certes, vous avez peut-être tort, mais vous entrerez dans une phase de votre développement, quelques itérations, quand vos suppositions seront généralement correctes, et il sera facile pour l'entreprise / le client d'obtenir un budget précis de combien d'histoires ils peuvent inclure dans une itération.

Une bonne règle dès le début, quand il est difficile d’estimer, est de prendre l’une de vos tâches les plus faciles et de l’attribuer à la valeur 1. Évaluez l’autre des autres utilisateurs par rapport à celui-ci et donnez le meilleur de vous-même. deviner. Si quelque chose est trop compliqué ou n'est pas clairement défini, vous serez obligé de lui attribuer un très grand nombre.

Un autre concept clé est que vous devez réévaluer les heures de chaque user story à chaque itération. À mesure que vos récits seront mieux définis et que votre estimation de votre vitesse s'améliorera, vous obtiendrez des temps plus précis pour vos récits.

En ce qui concerne les surprises, cela n’a aucune incidence sur l’estimation des user stories ... puisque vous n’avez pas de user stories qui représentent des surprises.

Answer 3

Steve McConnel dans " Estimation de logiciel: démystification de l'art noir " dit mieux que je ne le ferais:

  

"Comptez si possible. Calculer quand   vous ne pouvez pas compter. Utilisez le jugement seul   uniquement en dernier recours. "

Chapitre 7 - Compter, calculer, juger (PDF).

(merci de me rappeler cela):

Answer 4

Une technique mise en œuvre où je travaille. Pour chaque histoire d'utilisateur, écrivez-la sur un morceau de carte avec un en-tête. Demandez à chaque personne de prendre une carte et écrivez dessus le nombre d'heures qu'il pense qu'il lui faudra pour la terminer. Demandez-leur de placer les cartes contre la tâche sans se les montrer. Une fois que vous avez tous les résultats, regardez les chiffres et voyez les valeurs supérieure et inférieure. Vous obtiendrez normalement des chiffres assez proches les uns des autres.

Pour les valeurs ci-dessus ou ci-dessous, demandez au développeur ou à la personne qui a fourni l'entrée pourquoi, à son avis, cela prendrait-il si longtemps ou si peu comparé à la moyenne. Si l’équipe est parvenue à un consensus par opposition à un individu, cela signifie que tout le monde comprend la tâche.

C’est une idée tirée d’un livre que j’ai lu sur les techniques agiles et que j’ai oublié l’auteur pour le créditer.