Pourquoi ne faut-il pas estimer une User Story en unités de temps?

estimationPour estimer son backlog de sprint, il faut une unité de mesure. L’unité qui vient immédiatement en tête est le temps. Mais cette unité est en fait très difficile à appréhender. Je lui préfère la méthode dite des « Story Points »

Pourquoi ne pas utiliser le temps comme unité de mesure?

Comme nous l’a montré Albert, le temps est relatif. Prenons deux développeurs galiléens en mouvement :). L’un est senior, l’autre est junior. La même User Story sera terminée (voir Definition of Done) dans des intervalles de temps différents. Il est donc logique que ces deux développeurs aient préalablement donné deux estimations différentes. On retrouve peu de fiabilité dans cette mesure, donc.

Il est aussi difficile de mesurer le temps pris en considérant tous les facteurs qui empêchent de se consacrer au développement de sa User Story (une anomalie urgente à corriger, une réunion avec le Product Owner,… )

Comment estimer en utilisant la méthode des Story Points ?

Là où le comptage en temps tentait une mesure absolue (cette US va me prendre X heures), la mesure en Story Points est une mesure relative. C’est à dire qu’on va se baser sur une User Story de référence et lui donner un poids de référence. On peut par exemple prendre la plus petite User Story du backlog et fixer, tous ensemble, un poids de référence pour cette User Story. Ensuite, il suffira de prendre chaque User Story et de l’estimer relativement à celles déjà estimées.

Cette estimation prend en compte la complexité du développement, l’effort à fournir et le risque.

  • La complexité est la mesure de ce que ce que je dois comprendre pour résoudre le problème.
  • L’effort est la quantité de choses à faire pour terminer la User Story. On parle ici de tout ce qu’on sait qu’il faut faire, c’est la partie la plus évidente de l’estimation.
  • Le doute est tout ce que je peux supposer qu’il faudra faire pour terminer la User Story. Il est possible de soupçonner qu’on aura un refactoring du code existant à faire au préalable, qu’il faudra envisager de tester plusieurs solutions techniques….

Dans le cas idéal, le développeur n’a que l’effort à mesurer et il faut apprécier ce moment s’il se produit.

Mais j’ai quand même besoin de savoir à peu près combien de temps il me reste pour terminer mon projet!

Pas de problème! La mesure de la vélocité va nous permettre d’avoir une estimation du temps restant basée sur l’expérience.

Imaginons qu’un binôme de développeurs ait chiffré son Product Backlog avec un poids total de 40. Ils viennent de terminer la première itération de deux semaines de leur projet et ont développé un total de 17 points. Ils peuvent donc évaluer que le projet sera terminé dans un peu plus d’un sprint. Bien sûr, plus le nombre de sprints qu’ils ont derrière eux est important, plus cette estimation de temps par l’expérience va devenir précise.

A la différence de l’estimation directe du temps, l’estimation du temps par l’expérience est plus fiable car elle prend en compte la moyenne des facteurs qui empêchent de se consacrer à sa tâche de développement: j’ai développé en moyenne 15 points par sprint pendant 8 sprints, je sais que cette moyenne sur 8 sprints inclut une bonne moyenne des facteurs qui me détournent de ma tâche donc que ma prévision en temps, par rapport aux Story Points restants est assez précise.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s