Estimations

Les estimations en agilité doivent être réalisées par ceux qui réalisent (les développeurs), sur la base de ce qui a déjà été réalisé. Ce n'est pas au PO ou à un manager de faire l'estimation.

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 la marge 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é, le temps et l'incertitude de l'élément à réaliser.

Pour éviter les biais, le planning poker consiste à ce que ceux qui vont réaliser une fonctionnalité vont voter 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

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.

Les estimations ne doivent pas servir à donner des engagements et empêcher ensuite de prendre en compte des imprévus qui auraient de la valeur. C'est pourtant souvent l'intention de ceux qui demandent des estimations. Un des intérêts de l'agilité est de réaliser ce qui a le plus de valeur, l'imprévu est alors inévitable.


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/ http://blog.thiga.fr/product-management/extreme-quotation-estimer-la-complexite-de-son-backlog/

 

Copyright 2001-2016