Les estimations sont une bonne pratique

Tableau RelatifJ’avoue ne pas totalement accrocher avec le mouvement #noestimate.

Je comprends bien la volonté de gagner du temps (ou plutôt d’éviter d’en gaspiller) et je sais que l’on peut planifier des releases sans avoir besoin d’estimer chacune des User Story (@claudeaubry détaille cela précisément dans la version 4 de son livre sur Scrum – Ce qui lui  a d’ailleurs valu plusieurs remarques de ma part lorsque j’en ai fait la relecture).

D’autres personnes considèrent que dès lors qu’une estimation est donnée, elle est considérée comme un engagement et que tout engagement amène du mauvais stress sur l’équipe (la pression) et un biais potentiel sur la qualité de ce qui sera produit (afin de tenir l’engagement). Et donc qu’il est préférable de ne pas donner d’estimation pour éviter ces désagréments.

De la même façon, j’ai lu et entendu que puisque les managers ne comprennent pas l’utilisation des indicateurs agiles et qu’il est trop difficile de leur en expliquer le fonctionnement (ou peut être simplement qu’ils ne veulent pas entendre) alors le plus simple est d’arrêter de les produire. Donc plutôt que de s’occuper du problème réel, on fait disparaitre la conséquence en espérant que cela ira mieux … un doux rêve 🙂

De mon coté, je trouve que passer du temps à faire des estimations a de la valeur pour peu que l’on tienne compte des éléments suivants :

Continuer la lecture de « Les estimations sont une bonne pratique »

Piloter l’agilité avec la vélocité

Je rencontre pas mal d’équipes Scrum qui se posent la question de l’utilité de l’estimation des stories en points !

Ok, me disent-ils, nous savons que les points permettent de calculer la vélocité (i.e.: la vitesse de l’équipe), c’est à dire le nombre de points par durée fixe de temps ou itération (comme des km/h pour une voiture), mais chez nous, personne n’utilise la vélocité pour prendre des décisions, du coup, à quoi ça sert d’estimer en points ?

Effectivement, vu sous cet angle, l’équipe aurait raison d’arrêter une pratique qui prend du temps et qui ne leur sert à rien, et pourtant, un Product Owner bien informé dispose avec la vélocité d’un outil réel de pilotage Agile.

Ce que je recommande de mettre en place sur tous les projets que j’accompagne est … Continuer la lecture de « Piloter l’agilité avec la vélocité »

Comparer les vélocités

velociteAttention, je ne souhaite pas parler de comparaison de vélocité entre équipes distinctes, ce sujet a déjà été traité sur le blog de Mike Cohn de façon très claire et efficace. Je souhaite parler de comparaison de la vélocité des sprints pour une même équipe.

Le mois de mai vient de se terminer et les vacances d’été arrivent, ces 2 périodes sont propices à des prises de congés (bien mérités diront certains) qui influent sur la capacité de production de l’équipe puisque le nombre de jours disponible n’est pas identique d’une itération à l’autre.

Que faire dans ce cas ?

Continuer la lecture de « Comparer les vélocités »

La vélocité des bugs

bugs2Scrum définit la vélocité de l’équipe pour une itération comme étant la somme des points des User Story terminées à la fin de l’itération. L’évaluation de la valeur en points d’une User Story est souvent faite par l’équipe à l’aide du Planning Poker de façon autonome, il est donc vain de chercher à comparer des vélocités entre équipe (Cf. Du bon usage de la vélocité). Cette vélocité est un élément indispensable de la planification agile.

Mais le Product Backlog ne contient pas seulement des User Story puisque l’on y trouve également des exigences non fonctionnelles (souvent des demandes techniques demandées par l’équipe) et des bugs.

Alors les questions qui se posent sont :

  • Est-ce que la vélocité d’une exigence non fonctionnelle ou d’un bug a un sens ?
  • Doit-on estimer ces vélocités avec les mêmes pratiques ?

Continuer la lecture de « La vélocité des bugs »

Du bon usage de la vélocité

J’ai eu une discussion animée hier avec un ami qui cherche à convaincre une société de basculer dans une mode agile. Le point sur lequel nous avons loguement discuté était l’utilisation de la vélocité comme une mesure de performance de l’équipe et comme critère de maintient en poste ou pas d’une équipe de sous-traitants.

De mon point de vue, la vélocité est une mesure de capacité de production qui est lié à une équipe et une seule dans le contexte spécifique d’un projet. Au grand damme des managers classiques, il n’est malheureusement pas possible de comparer les vélocités entre équipes pour savoir si l’une est meilleure que l’autre et si un sous-traitant travaille mieux qu’un autre.

Lorsque la vélocité est calculée, et je recommande fortement de le faire, je l’utilise principalement de 3 façons différentes (liste non exhaustive bien entendu) : Continuer la lecture de « Du bon usage de la vélocité »