eXtrême Quotation par exemple. Dans les méthodes traditionnelles, il était courant de donner des estimations en jours-hommes. En agile, il est conseillé d’estimer soit en taille de T-shirt (XS, S, M, L, XL, XXL) ou en “story points” (points de complexité) suivant le suite de Fibonacci (1, 2, 3, 5, 8…).
Pour les développeurs, ce n’est pas la tâche la plus simple…
@CommitStrip_fr: Ah, c'est pas comme ça le Scrum planning poker ?
http://t.co/Phnwq2E89w pic.twitter.com/Rgr6ACGXei @MorrrganG #PlanningPoker— Matthieu Bréchet (@mbrechet) 23 janvier 2015
La première raison d’estimer est pour pouvoir répondre à la question “Quand est-ce que j'aurai cette fonctionnalité ?” des parties prenantes . Cela permet de prédire “Combien de temps cela va nous prendre ?” et “Qu’est-ce que l’on aura à telle date ?”.
Quand j'entends parler d'estimations :) pic.twitter.com/HbsTZOlFSM
— Yoan Lureault (@ylureault) 27 avril 2018
La deuxième raison est que cela facilite la priorisation : on va plutôt faire en premier ce qui a beaucoup de valeur et peu de complexité.
Using a Value Complexity Matrix to order your backlog | https://t.co/LapaFikIQW #BAoT #PMoT #ScrumMaster #ProductOwner pic.twitter.com/25Jl9GYa5W
— Dave Saboe (@MasteringBA) 24 mars 2018
Utilisation d’une matrice de complexité/valeur pour ordonner votre backlog #PMoT #ScrumMaster #ProductOwner
Les estimations ne sont pas un engagement ou une promesse de livraison. Elles aident au pilotage d’un projet afin de :
Mesurer la vélocité de l’équipe,
Visualiser la quantité de travail à faire en comparaison de la vélocité avec burn down/up chart.
Ces métriques sont mises à jour tout au long du projet afin de se projeter vers une date de livraison et d’agir sur le périmètre si besoin.
Si vous cherchez à avoir des meilleures estimations, voici un conseil révélé par un twittos :
Instead of focusing on making “better” estimates ...
focus on:
- working smaller
- integrating frequently
- exposing work to users/customers sooner
- testing assumptions earlier
- limiting dependencies
- less fragile code
- limiting handoffsYour estimates will improve#agile
— John Cutler (@johncutlefish) 7 octobre 2018
_Au lieu de vous concentrer sur de «meilleures» estimations … se concentrer sur: travailler plus petit, intégrer fréquemment, exposer le travail aux utilisateurs / clients plus rapidement, tester les hypothèses plus tôt, limiter les dépendances, avoir un code moins fragile, limiter les transferts. Vos estimations vont s’améliorer.
_
Si vous suivez les réseaux sociaux, le débat #NoEstimates affole la toile depuis quelque temps.
Discussion assertive entre collègues Agilistes sur le NoEstimate ... pic.twitter.com/4bnS8ZI2hN
— Gilles Agile (@LeCompteAGilles) 27 avril 2018
Ce débat est apparu après le constat suivant : sur certains projets, que l'on dimensionne par story point ou par nombre de stories dans un sprint, le suivi de la cadence restait sensiblement le même. Il valait donc mieux se concentrer sur la création de valeur.
《 Demander une estimation sur un projet à un développeur revient à demander à un attaquant combien de buts il marquera dans la saison. 》 #NoEstimate https://t.co/6cddhftRpR
— Jérôme Mainaud (@jxerome) 21 mars 2018
D’ailleurs, des octos en ont fait leur retour d’expérience : #NoEstimates : un an de projet, faisons le bilan.