Catégorie : Théorie

C’est pour les équipes qui utilisent les estimations probablement la dernière étape pour passer le ticket en ready (DoR)

Pourquoi estimons-nous?

Réduire au maximum les risques

La session d’estimation sert à mettre au jour et diminuer les zones d’ombre et risques du projet.
Une fois ces dernières connues, on peut choisir comment les traiter:

• Un Spike. Il est utilisé quand on ne connait pas encore la solution technique qui peut être apportée à un problème (idéalement, on fera un ou plusieurs POC).
• Inclure cette inconnue dans l’estimation.

Servir de support à la prise de décision et à la priorisation

Avant de développer une fonctionnalité, il est intéressant d’avoir une idée de son coût.
Une entreprise qui investit doit pouvoir estimer son ROI (retour sur investissement), cette information servira également dans la priorisation du backlog, c’est la raison pour laquelle il est possible qu’une story
estimée ne soit jamais développée.
Quand une application doit être mise en production, en fonction du nombre de sprint disponible et du
« coût » de développement, on priorisera différemment certaines features.
Faut-il engager plus de développeurs, testeurs, analystes et techniques pour augmenter la valeur livrée?

Établir la confiance

Pour que la confiance règne entre les parties prenantes d’un projet (clients, décisionnaires, PO), il faut
que l’équipe soit fiable sur sa capacité à livrer ce qui est promis. Les estimations nous guident dans
ce que nous devrions être capables de livrer dans un futur plus ou moins proche.
Grâce à cette donnée objective, nous pourrons plus facilement négocier le périmètre des releases

Aligner lʼéquipe et partager lʼinformation

Les estimations permettent de sʼassurer dʼune compréhension commune du périmètre, de la valeur à
produire et de se mettre dʼaccord sur la « taille » dʼune fonctionnalité.

Pour découper les User Stories (US)

Quand nous lisons, comprenons et estimons un ticket, nous pouvons parfois nous apercevoir que cette
dernière est trop importante.
Dans ce cas, nous le divisons en ticket plus petit. Nous augmentons la granularité du backlog et
renforçons la prédictibilité du travail.

Pour organiser le sprint backlog produit du point de vue de la valeur, de l’effort.

Si nous connaissons lʼeffort nécessaire à la réalisation dʼun ticket, nous pouvons déterminer si ce dernier
est réalisable dans le sprint.

Planification

Cʼest également un bon moyen pour estimer le nombre de sprint nécessaire à la réalisation des tickets
souhaités dans une release via un forecast.
On peut également communiquer plus facilement les causes d’un changement de plan, par exemple, si
l’on découvre que l’intégration d’un système à notre application est plus complexe que prévu, on peut
aisément démontrer l’effet sur ce que nous avions prévu.

Que représente une estimation?

Nous allons ici explorer plusieurs hypothèses sur le que/quoi et le comment estimer, selon quelle métrique.

Des jours hommes / du temps?

• L’humain est incapable d’estimer correctement son temps
• Une date ne prend pas en compte les facteurs externes tels que les emails, les meeting, les conversations informelles, lʼaide apportée par un développeur à un autre …
  (Habituellement, nous considérons quʼun développeur développe environ 6h/ jour)
• Le temps / les dates ont une valeur émotionnelle qui finira par oppresser les développeurs et le
  poussera soit à diminuer la qualité de son travail pour gagner du temps, soit à augmenter le temps
  prévu.
• Le temps nécessaire pour un développeur ne sera pas le même que pour un autre.

Pour illustrer mon propos

Prenons le cas d’une course à pied selon le point de vue d’un analyste ayant fait un Iron Man et d’un
Scrum Master de 110 kg.

Si on demande une estimation en temps pour les 20km de Bruxelles, le premier répondra 2h30, le
second 6h (sans certitude de terminer).
Ajoutons à cela que c’est une tierce personne qui va courir le jour J, il est totalement impossible de prédire le temps qui sera nécessaire. (Même un calcul savant donnerait une réponse erronée).
En revanche, si on demande d’estimer l’effort, la réponse sera pour les deux 20km.
Et si demain on parle d’un marathon, on sait que l’effort est peu ou prou le double.

Pour les tickets, c’est la même chose, si on estime en jours/homme, on doit savoir qui fera la tâche.

De la complexité?

Au plus c’est complexe à réaliser, au plus la valeur de l’estimation serait élevée, et inversement.
C’est en effet un point de départ intéressant, mais qui a ses limites.

Pour illustrer mon propos

Considérons une équipe de deux personnes composée d’un enfant et d’un chirurgien du pied.
Considérons 2 tickets (Nous supposons que les activités prennent le même temps.), construire 1000 personnages Lego et réaliser une reconstitution du pied (le pauvre a marché sur une brique).

Si nous parlons complexité, l’opération du pied aura une estimation bien plus élevée que le montage des personnages.
Si le but était de planifier et de savoir quand l’équipe aurait terminé, puisque le temps de réalisation est plus ou moins identique, l’estimation aurait dû être la même.
En fait, on peut dire que si la complexité des tâches varie, l’effort à fournir est comparable.

Un risque

Dans cette hypothèse, nous considérons qu’au plus le travail est risqué, au plus l’estimation devrait être élevée, et inversement. C’est assez risqué de prendre uniquement cette donnée pour une estimation.

Pour illustrer mon propos

Considérons l’estimation de la durée du voyage maison boulot en transport en commun et en trottinette.
Le transport en commun est plus rapide, mais « risqué » (Présence de bouchon, des gens dans les voies
(oui, la SNCB dit bien dans les voies).
La trottinette, même électrique, c’est plus « sûr », mais c’est lent (oui bon, on ne va pas prendre en considération le nombre de personnes aux urgences après une chute).
Une estimation en risque serait plus élevée pour le transport en commun, cependant, il est tout à fait possible que vous arriviez plus vite en bus qu’en trottinette au boulot demain. (Si demain est un weekend, ne vient pas au bureau).

Mais alors quoi?

Et bien, nous devrions surtout parler d’une notion d’effort qui reprendrait toutes les hypothèses précitées. La quantité de travail à fournir, sa complexité, ses risques et inconnues, le temps.

Quelle mesure pouvons-nous utiliser pour représenter l’effort?

D’autres articles suivront sur ces différentes mesures.

Pourquoi parler de relativité (E=mc²)?

Reprenons notre exemple de course, si notre première estimation était faite pour une course de 20 km,
nous pouvons aisément estimer que l’effort nécessaire à 10km sera de 1/2 tandis que l’effort pour 40km
sera le double.
De la même manière, les autres mesures permettent à l’équipe un accord sur la taille relative des tickets.
Par exemple, la story 2 représente 1/2 des efforts de la 1. La story 3 représente 2 fois la somme d’effort de la première.

Estimer de manière relative prend en compte l’imprécision de nos estimations. En effet, les humains ne sont absolument pas doués pour ce genre de chose, par contre, ils sont tout à fait capables de comparer 2 choses entre elles.

Revenons à nos Lego, en voyant un tas, vous ne seriez pas en mesure de donner le nombre de briques qui le compose, par contre, vous pouvez comparer 2 tas et dire qu’il y en a plus dans celui-ci.
Vous pourriez également dire qu’ils sont à peu près identiques …

On peut faire le même exercice avec des verres d’eau (ou de Vodka).

• Le premier verre est la référence
• Nous pouvons estimer que le second est plus rempli
• Le troisième est aussi rempli que le 1er (à moitié vide, ou moitié plein …)

Points d’attention

Variation du résultat par rapport au travail à fournir

Nous devons garder à lʼesprit que même si lʼéquipe est normalement capable de développer entièrement le produit, nous travaillons avec des spécialistes. Donc, si durant une période donnée, il y a moins de travail dans un domaine, la quantité de travail fournie par l’équipe va mécaniquement diminuer.

Précisions

Il est impossible d’obtenir un chiffre précis quoi que nous fassions.
Par contre, au fil du temps, pour une équipe stable, la corrélation estimation de l’effort et nombre de
tickets done dans un sprint sera de plus en plus exacte, et donc, la prédiction moyen terme également.