Estimations

En agilité, on parle d'estimations collectives au lieu d'estimations individuelles. Les estimations en agilité doivent être réalisées par ceux qui réalisent (les développeurs), même si le Product Owner peut chercher à comprendre pourquoi il y a cette estimation afin de revoir éventuellement sa demande. Quoiqu'il en soit, ce n'est pas au Product Owner ou à un manager de faire l'estimation.

Une estimation par les membres de l'équipe permet avant tout la discussion pour bien comprendre ce qu'il y a à réaliser, et de découper les grosses stories. Il est inutile de passer beaucoup de temps sur les estimations (ce qui n'amènent pas de valeur) sachant que la "précision des estimations" ne sera jamais bonne.

 

Pourquoi estimer en points d'efforts plutôt qu'en jours homme ?

Imaginons une nouvelle fonctionnalité dans un logiciel. Le développeur expérimenté va l'estimer à 2 jours, le développeur lambda va l'estimer à 4 jours alors que le nouvel arrivant va l'estimer à 10 jours. Et ça c'est dans le meilleur des cas, car bien souvent tout le monde s'aligne sur le sachant et au final on ne tiendra pas les délais ! Quoi qu'il en soit, l'estimation en jours homme d'une User Story sera dépendante des personnes qui travailleront dessus.

En utilisant les points d'effort, les différents membres de l'équipe auront les mêmes estimations.

Pour arriver à cela, commencer tout d'abord par définir des User Stories de référence. Une User story à 1 point, Une autre user story à 2 points, une user story à 3 points, une à 5 points.

Les estimations se font principalement avec :
- la suite de Fibonacci : 0, 1, 2, 3, 5, 8, 13, 21... (plus l'élément estimé est important, plus l'incertitude est importante)
- les tailles de tee-shirt : XS, S, M, L, XL...

L'estimation représente l'effort à fournir. Cet effort est aussi appelé complexité, mais ce terme peut prêter à confusion car l'effort représente la complexité, la durée et l'incertitude de l'élément à réaliser.

Le Product Owner présente une user story. Tous les membres de l'équipe de développement posent des questions pour bien comprendre ce qui doit être réalisé et comment le réaliser.

Pour éviter les biais, le planning poker consiste à ce que ceux qui vont réaliser une fonctionnalité votent en simultané (on dispose de user stories de référence, comprises de tous). On interroge généralement ceux qui ont les estimations les plus éloignées pour voir si des aspects n'auraient pas été vus, et on revote. Explications

L'équipe pourra alors définir par exemple que la user story vaut 3 points, car par comparaison, elle demande le même effort que la user story de référence à 3 points.

Ces 3 points correspondent pour l'un à 2 jours, un autre à 4 jours et le dernier à 10 jours, mais pour tous le même nombre de points d'effort.

 

Capacité et vélocité

Au global, on détermine le nombre de points qu'est capable de réaliser une équipe en une itération (capacité) de façon empirique, c'est à dire en se basant sur l'historique, tout en prenant en compte les éventuelles absences, le turn-over...

Avec une équipe stable, le nombre de jours homme réalisés n'évoluera pas, par contre, le nombre de points réalisés à chaque itération (la vélocité) évoluera en fonction de la montée en compétence, du turn-over...

Vélocité vs Débit

La vélocité représente un nombre de points d'effort réalisés sur une cadence/sprint. Le débit représente le nombre d'éléments réalisés sur une  cadence/sprint, cela oblige à ce que toutes les cartes soient de tailles similaires. Plus les cartes sont découpées finement, plus l'estimation est précise. L'effort pour réaliser une story à 2 points et une autre à 3 points n'est pas le même qu'une story à 5 points car la story à 5 points à un degré d'incertitude supplémentaire (le 5 de la suite de Fibonacci équivaut à un effort entre 4 et 7).

 

Planification de Sprint

Comment gérer (ou minimiser) l'imprévu ?

Bug de recette. Plus les User Stories seront découpées finement et que l'équipe travaillera en flux tiré, plus les bugs de recette seront étalés durant le sprint. L'équipe de développement doit prendre en compte cet imprévu en se basant sur les précédents sprints. 

Bug de production. Imprévisibles, l'équipe de développement doit donc prévoir une bande passante (par exemple 10 ou 20% de la capacité, en fonction des sprints précédents) pour gérer les bugs de production pendant le sprint.

Demandes urgentes du management. Le Scrum Master est là pour protéger l'équipe des perturbations extérieures. Les managers, parties-prenantes... doivent passer par le PO qui lui verra avec l'équipe de développement ce qui pourrait être retiré du sprint backlog pour prendre cette nouvelle demande. Cela ne perturbera généralement pas l'équipe si celle-ci travaille bien en flux tiré, et qu'elle n'a donc pas tout commencé.

Travail plus important que prévu. Pour que l'équipe s'engage, il faut qu'elle ait bien compris ce qu'il y a à faire sur chacun des éléments du Sprint Backlog, ce qui passe par exemple par une estimation via du Planning Poker. Le Definition of Ready, non obligatoire en Scrum, mais recommandé consiste à définir un ensemble de critères pour déterminer les éléments qui peuvent êtes pris dans un Sprint (comment s'engager sur un périmètre si on ne sait pas quoi tester par exemple. Les ateliers "3 amigos" sont de plus en plus répandus ; ils consistent à ce qu'un développeur, un testeur et le PO discutent de la User Story (rédaction de la US et des acceptances tests) avant d'être développée pour minimiser les incompréhensions entre le représentant de l'utilisateur (PO), les développeurs et les testeurs.

 

Extreme quotation

Technique permettant d'estimer les éléments d'un backlog très rapidement.

Déroulé d'ateliers : https://blog.octo.com/extreme-quotation-planning-agile-sous-steroides/