Estimations, mesures, indicateurs
Chapitre quinze de Scrum édition 3

La troisième édition de mon livre Scrum a été publiée il y a un an. Depuis, plus de 2000 exemplaires ont été vendus. Pour ces lecteurs, que je remercie bien chaleureusement, je fournis régulièrement des suppléments en ligne.
Voici ceux qui portent sur Estimations, mesures et indicateurs, le chapitre 15 de la troisième édition.
Le but du chapitre
Ce chapitre présente les indicateurs d’un développement avec une méthode agile et montre comment les obtenir, avec quelles mesures et à partir de quelles estimations.
Le résumé
Il figure page 226.
Les mesures agiles sont différentes. Elles diffèrent dans leur nature avec l’importance donnée aux résultats visibles (vélocité calculée avec les stories finies). La vélocité repose sur des estimations, faites de façon relative, sans unités. Les indicateurs, élaborés à partir des mesures, sont utiles pour le suivi des plans ; ils servent aussi à l’équipe pour qu’elle évalue ses progrès et améliore ses pratiques.
Changements dans les éditions successives
Ce chapitre fait maintenant 14 pages, soit beaucoup moins que dans les éditions précédentes, où il en faisait plus de 18. J’ai élagué pour recentrer sur les quelques indicateurs essentiels.
J’ai aussi revu les notions présentées dans §15.1 sur l’estimation de la taille et de la valeur :
- je parle de difficulté intrinsèque plutôt que d’effort (employé dans l’édition 2) ou de complexité (on parle souvent de points de complexité, pas moi),
- j’expose mon scepticisme sur les estimations de la valeur, préférant des mesures sur les impacts attendus (voir le chapitre 13).
- Comme indicateur, j’introduis le diagramme de bacs cumulés (empilés), en complément à la notion de bac à stories (voir le chapitre 5).
Ce que je changerais si j’écrivais une édition 4
- J’approfondirais l’idée, déjà évoquée, de compter plutôt que d’estimer, dans le sillage du mouvement #noEstimates. Pas d’estimation, mais des mesures et des indicateurs quand même.
- Je proposerais un indicateur permettant de suivre l’avancement sur les features (pas des stories) dans un cadre contractuel.
Liens cités dans le chapitre
- Le livre Exploring Scrum de Dan Rawsthorne & Doug Shimp pour la notion de difficulté intrinsèque, une idée de Ron Jeffries au départ.
- Wikipedia pour la notion d’utilité.
- Le backlog en couleurs de Philippe Kruchten, lien vers la présentation, revue en décembre 2013.
Lectures en relation
- Le Raid Agile
- De la valeur à l’utilité
- L’estimation par similitude d’effort
- Commentaires
- Errata
- Les suppléments des chapitres précédents