Qu’est-ce que l’estimation Agile ?

Que ce soit une équipe qui développe un produit ou un projet, nous devons répondre à la question : « Quand pouvons-nous le terminer ? » ou « Dans quelle mesure pouvons-nous le livrer à une date donnée ? » Tout comme dans les modèles de développement traditionnels, nous devons estimer la charge de travail avant de commencer un projet.

L’estimation Agile présente les trois caractéristiques suivantes :

Estimation collaborative par l’équipe

Dans Scrum le développement, l’équipe partage la responsabilité et travaille collectivement vers chaque Sprint. Par conséquent, les équipes Agile utilisent des techniques d’estimation collaborative pour estimer la charge de travail. L’estimation collaborative utilise généralement le Poker d’Estimation comme outil, où l’équipe joue collectivement à un jeu d’estimation. Le Poker d’Estimation est considéré comme l’une des techniques les plus efficaces et les plus engageantes pour estimer l’effort dans le développement Agile le développement. Il se compose d’un ensemble de nombres semblables à ceux de Fibonacci : 0, 0,5, 1, 2, 3, 5, 8, 20, 40, ?, ∞. Chaque jeu contient quatre ensembles de ces nombres de Fibonacci, conçus pour être utilisés par jusqu’à quatre membres de l’équipe.

Précision de l’estimation collective par rapport à l’estimation individuelle

Une étude sur la précision de l’estimation de l’effort entre individus et groupes dans une expérience de projet logiciel a révélé que 20 professionnels du logiciel de la même entreprise ont estimé séparément l’effort nécessaire pour mettre en œuvre le même projet logiciel. Les participants avaient des profils et des rôles, et le projet logiciel avait déjà été mis en œuvre précédemment. Plus tard, ils ont été regroupés en cinq équipes. Chaque équipe a discuté et combiné leurs connaissances pour s’accorder sur une estimation unique.

Résultat : les estimations fondées sur la discussion en groupe étaient plus précises que les estimations individuelles.

Étapes pour jouer au Poker d’Estimation

1. Chaque membre de l’équipe reçoit un jeu de cartes contenant : 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞ — un total de 12 cartes.
2. Le Product Owner lit la description de l’histoire utilisateur ou de la fonctionnalité à l’équipe.
3. Les membres de l’équipe discutent de la fonctionnalité et posent des questions au Product Owner si nécessaire.
4. Après la discussion, chaque membre sélectionne une carte représentant son estimation et la révèle simultanément.
5. Si les estimations diffèrent fortement, l’équipe discute : sommes-nous d’accord ? Quels facteurs ont été négligés ? La personne ayant l’estimation la plus élevée ou la plus faible doit expliquer sa justification avant le prochain tour de vote.
6. Après discussion, l’équipe peut passer par un autre tour jusqu’à atteindre un consensus.
7. Retour à l’étape 2 et commencez à estimer l’élément suivant de la liste de backlog.

Estimer la taille, pas le temps — utiliser l’estimation relative plutôt que l’estimation absolue

L’estimation est simplement une estimation éclairée. Nous utilisons toutes les connaissances et l’expérience disponibles pour estimer combien de temps cela prendra. Plutôt que d’évaluer chaque nouvel élément de travail de manière isolée, pourquoi ne pas le comparer aux éléments déjà terminés ? Les humains sont meilleurs pour se rapporter à des objets de taille similaire que pour deviner des tailles absolues.

Par exemple : est-il proche de cet objet très petit ? Ou plutôt semblable à ce projet de taille moyenne ? Ou vraiment grand, comme celui que nous avons terminé le mois dernier ? L’estimation relative réduit non seulement le temps consacré à l’estimation, mais améliore également significativement la précision.

Notre cerveau n’est pas bon pour l’estimation absolue — nous comparons toujours de nouveaux éléments à estimer à ce que nous connaissons déjà.

Estimation des points d’histoire

Estimation de la vitesse — Enregistrement et moyenne de la vitesse de l’équipe par sprint

La vitesse de l’équipevitesse est le nombre de points d’histoire l’équipe Scrum termine réellement pendant un sprint. La vitesse de l’équipe vous indique à quelle vitesse l’équipe travaille. Pour un nouveau projet ou une nouvelle équipe (sans historique de vitesse antérieure), nous pouvons réaliser 1 à 2 sprints pour mesurer et établir une vitesse initiale. Pendant l’exécution du sprint, nous enregistrons la vitesse de l’équipe à chaque sprint pour la planification future.

Estimation de la vitesse de l’histoire utilisateur

Nous estimons le nombre total de points d’histoire dans le Backlog produit. Connaissant la vitesse moyenne par sprint, nous pouvons calculer le nombre de sprints nécessaires pour terminer le projet — ce qui permet d’estimer la durée du projet. Comme indiqué dans la figure ci-dessous.

Estimation de la durée du projet Scrum