Discussion :

[randriano]

L'estimation en informatique fait encore débat. On dit qu'en Agile il n'y a pas d'estimation du tout, c'est le mouvement #NoEstimates

ce qui est sûr c'est qu'il n'y a pas d'estimations en temps en AGILE.

Explication très claire:

STORY POINT: c'est toujours estimé uniquement par les personnes qui vont faire le travail
En informatique, ce sont donc essentiellement les développeurs. On l'appelle quelquefois POINT DE COMPLEXITÉ: point = 1 pour une fonctionnalité très très simple et point = 13 par exemple lorsque c'est complexe

VALUE POINT: c'est estimé par les consommateurs du produit. En cas réel ce sont donc les gens en dehors de l'équipe de développement: un product manager, les gens du marketing, les managers et cetera. Par exemple un point = 21 est une fonctionnalité de grande valeur pour le consommateur.

[4sStylZ]

Hello,

Merci pour ton post, en effet No-Estimate à le vent en poupe. Je suis en désaccord avec quelques définitions et affirmations.

Attention, No-Estimate a été créé sur le constat (selon le Chaos report) que toutes estimations sont à 75% incorrecte. Ce n'est pas parce que les estimations sont incorrectes qu'elles sont sans valeur pour développer un produit ou un projet ! Les estimations sont aussi importante pour prendre des décisions, confronter des idées, et la manière dont elles sont réalisées amène souvent à apporter une meilleur connaissance de ce qu'on vas produire.

---

No Estimate ce n'est pas « ne pas estimer ». C'est une méthode qui permet l'estimation des items et donc la charge de travail géneral en se basant sur le nombre d'items. Cela sous entend qu'ils soient systématiquement découpés / raffiné avec le même degré de détail.

---

ce qui est sûr c'est qu'il n'y a pas d'estimations en temps en AGILE.

Euh… non. Rien n'est « sûr ». Beaucoup de monde (dont je fais partie) considère que le temps n'est pas un bon outil de mesure mais rien n'est normé ou quoi que ce soit.
Agile c'est un mindset, et si tu fait référence au manifeste agile ou aux guides des frameworks reconnus (SCRUM, XP etc) tu ne verra pas de mention de « comment » estimer les choses.
Il y a des équipes Scrum qui choisissent d'estimer avec du temps, et pour certains ça marche très bien. En déplaise aux puristes…

Pour ce qui est des story points, effectivement en France il y a beaucoup de monde qui résume ça aux points de complexité. Pourtant ce n'est pas recommandé et cela peut être très compliqué et surtout peu représentatif (e. g. Quid d'une tache très simple à faire mais qui demande un gros effort, ou qui implique un périmètre très important, ou qui est très risquée ? »).
Beaucoup d'équipes utilisent CURSE pour l'estimation.

C is for Complexity. This is how complicated, intricate, involved, integrated, etc. the work for a story will involve.
U is for Uncertainty. This facet constitutes the certainty (or lack thereof) for the work that needs to be done. The team may be unfamiliar with the technology or uncertain how a particular element of the story may impact architecture or design.
R is for Risk. This encompasses how dangerous a requested change or enhancement may be to the overall system, design, or architecture.
S is for Scope. Scope is how much work or how far-reaching particular changes are.
E is for Effort. This is what we typically associate with story points. It represents the actual work that’s going to be done, the implementation of the user story.

Pour s'en souvenir on peut utiliser aussi le mnémonique « PRICE » pour se souvenir des mots Français : Perimètre, Risque, Incertitude, Complexité et Effort.

---

J'ajouterai pour finir que le terme utilisé couramment pour ce que tu appelle la valeur est la « Business value ».

[randriano]

Merci pour votre retour pertinent.

Concept intéressant: CURSE