Notre Rythme Estime Mieux !
Introduction
Dans mon équipe, on estimait en taille de T-Shirt l’effort à fournir pour répondre à un besoin métier.
Après plusieurs versions, on s’est permis de déduire la correspondance en jours-hommes en fonction de notre rythme dans le passé (XS = 1/2 jour, S = 1 jour, M = 2 jours, etc…)
Certes, cela rassurait le métier et le Product Owner, mais on se retrouvait souvent avec une partie du périmètre à retirer pour respecter la date de livraison. Cette décision se prend tardivement lorsque nous parions à fond sur nos estimations.
La question posée au sein de l’équipe : pourquoi continuer à donner une estimation qui s’avère inexacte ? Sachant qu’on livre toujours ce qui est opérationnel (terminé et testé).
Pourquoi on estime ?
Au début d’un projet, le métier veut généralement connaître le temps nécessaire pour sa réalisation et par conséquence le budget. La connaissance de cette information augmente le niveau de confiance pour atteindre l’objectif dans les temps (Time-To-Market) et dans les limites du budget disponible.
Evaluer l’effort à fournir pour accomplir l’ensemble des tâches, reste la technique classique et la plus connue pour estimer. Le livrable de cette technique est une simple prédiction qui peut être exacte avec beaucoup de chance mais aussi incertaine dans la plupart du temps.
La précision des estimations au début d’un projet peut avoir une incertitude de 4 fois. Cela signifie que l’effort (ou le coût) estimé d’un projet est compris dans une plage de 1/4 à 4 fois l’estimation exacte.
Cette incertitude se réduit au fur et à mesure qu’on avance dans le projet.
Comment livrer un projet sans décaler le time-to-market ?
On livre à temps un projet si on sait qu’on est en retard. Obtenir tôt cette information nous permet de prendre des décisions pour ajuster l’engagement métier sans rater le rendez-vous TTM.
Pour prendre et appliquer ces décisions il faut remplir les recommandations ci-dessous, tout au long de la réalisation du projet :
- Découper le besoin d’une façon permettant d’ajuster le périmètre ;
- Mesurer la progression pour tirer des informations qui aident à prendre des décisions ;
- Ajuster le reste à faire suite aux décisions prises.
Je détaille dans la suite chaque recommandation.
Bien découper le périmètre en user-story :
En mode Agile, les besoins fonctionnels sont découpés en user story (US). Les US doivent remplir certains critères pour rendre leurs manipulations flexibles.
Les US doivent être indépendantes, pour que la suppression ou le décalage des cartes n’impacte pas le reste du périmètre.
L’avancement des US avec une vraie valeur métier, représente le vrai avancement du projet. Le découpage fonctionnel avec l’affectation d’une valeur métier, aidera également à prioriser.
En plus des deux critères, des US suffisamment petites permettront d’avoir un rapport d’avancement plus régulier.
Donc, un découpage en US respectant les trois critères permettra d’avoir :
· Une flexibilité pour manipuler le périmètre du projet;
· Un avancement partagé par tout le monde y compris le métier ;
· Un rapport d’avancement régulier.
Plusieurs techniques existantes pour un découpage garantissant les trois critères, dépendance, granularité et valeur, à savoir : les ateliers Story Mapping, l’Event Storming et l’Event Modeling.
Mesurer l’avancement réel pour prendre des décisions
Partant du septième principe du manifeste agile :
« Un produit opérationnel est la principale mesure d’avancement »
Cela implique que l’avancement réel du projet est donc le nombre de fonctionnalités opérationnelles, testées et validées par le métier.
Le test et la validation des fonctionnalités en présence du métier peuvent se faire à plusieurs points dans le flux de travaux :
- Juste après la fin des développement (pair-test) ;
- Lors des démos ;
- Ou en phase de recette.
Le plus tôt obtenir les feedbacks du métier, le mieux c’est.
Raisonner avec le nombre de fonctionnalités opérationnelles, testées (Running-Tested-Stories) par petite cadence (semaine par exemple), permettra de connaître le débit réel de l’avancement.
A ce stade nous pourrons avoir une prédictibilité sur le temps qui reste. Cela nous permettra de voir si nous respecterons la deadline.
Dans l’exemple ci-dessus, on peut voir que l’équipe ne finira pas toutes les cartes du backlog avant la date de fin des développements.
A présent l’équipe et le métier possède suffisamment d’informations pour prendre des décisions.
Ajuster le backlog du reste à faire
Ajuster un backlog veut dire rajouter, supprimer ou décaler des US en fonction de l’avancement du projet.
Par exemple si nous disposons de 4 semaines pour la prochaine livraison, et nous avons 8 stories que nous devrions livrer, notre débit moyen doit être 2 stories par semaine.
A ce stade on va se baser sur notre débit moyen de stories opérationnelles et testées par semaine :
- Réduire notre périmètre si notre débit moyen est inférieur de 2 US(stories)/semaine
- Augmenter le périmètre si notre débit moyen est supérieur à 2 US/semaine.
Il n’y aura pas de problème pour ajouter, supprimer ou décaler une US puisqu’on a des briques indépendantes avec possibilité de les prioriser en fonction de la valeur métier.
Conclusion
Pour ma propre expérience en tant que Scrum Master, la bascule vers le mode #NoEstimates a été faite d’une façon naturelle.
Aujourd’hui, en suivant les recommandations que j’ai décrites ci-dessus, nous avons :
- Une réutilisation du temps que nous prenions pour estimer ;
- Une prédictibilité basée sur des indicateurs reflétant la réalité ;
- Un périmètre flexible et ajustable sans effet dominos ni gaspillage ;
- Un avancement réel qu’on partage avec le métier.
Par contre l’autonomie du métier à interpréter les indicateurs, reste un axe à améliorer.
Et pour finir, s’il y a un conseil à donner, c’est surtout éviter de prononcer trop le mot #NoEstimates en présence du métier. Car cela donne l’impression qu’on n’estime pas. Alors que l’approche consiste à améliorer notre prédictibilité, en partant sur une bonne base qui est :
- Un périmètre bien découpé ;
- Et des indicateurs qui reflètent l’avancement réel du projet.
Références :
https://www.amazon.fr/NoEstimates-Measure-Project-Progress-Estimating-ebook/dp/B01FWMSBBK
Révisé par : Emmanuel Lehmann / Benjamin Seillier / Mathieu FLAMERION / Silvere DUVAL / Geoffrey Sautieres
Les dessins sont réalisés par l'auteur (j'espère qu'ils vous plairont :)
