A Devoxx France, Petra Cross nous a donné sont point de vue sur l'agilité telle qu'elle est utilisée chez Google dans son talk "Day to day software development at Google" pour être efficace et éviter de perdre trop de temps. Je trouve interessant de poster à ce sujet, car nous avons toujours du mal a estimer les user stories de manière abstraite et avons tendance à pendre trop de temps dans la négociation (et s'égarer dans les explications). Petra nous donne des astuces intéressantes pour mieux mettre en place son planning poker.
Comment s’abstraire du temps dans la macro-estimation des user stories ?
L’estimation des stories se fait normalement de manière abstraite. On parle de macro-estimation en point. Je m’explique. L’estimation des stories ne doit pas être faite avec la notion de temps (durée prévue pour la réalisation en jours/homme) mais avec une notion de points sans unité.
Pourquoi cette abstraction ? Car elle permet de mieux estimer une story et éviter les écarts de temps en fin d’itération. En voulant macro-estimer en j*h, on va faire en sorte que la somme des estimations de tâches corresponde avec l'estimation de la story. Or, le résultat est forcément biaisé, car la macro-estimation suit une suite de Fibonacci (1, 2, 3, 5, 8…) et ce qui va induire des décalages dans les estimations qui, elles, ne sont suivent pas cette suite.
Pourquoi cette abstraction ? Car elle permet de mieux estimer une story et éviter les écarts de temps en fin d’itération. En voulant macro-estimer en j*h, on va faire en sorte que la somme des estimations de tâches corresponde avec l'estimation de la story. Or, le résultat est forcément biaisé, car la macro-estimation suit une suite de Fibonacci (1, 2, 3, 5, 8…) et ce qui va induire des décalages dans les estimations qui, elles, ne sont suivent pas cette suite.
Alors comment bien macro-estimer ?
Il faut pouvoir juger de la complexité d’une story et non pas de son temps de réalisation prévu. L’idée est de définir, avant le début du premier sprint (et donc avant les premières estimations) 2 étalons sur des stories déjà réalisées par l’équipe et dont tous les membres maîtrisent la complexité. Tous les membres de l’équipe doivent se mettre d’accord pour définir ce qu’est :
Il faut pouvoir juger de la complexité d’une story et non pas de son temps de réalisation prévu. L’idée est de définir, avant le début du premier sprint (et donc avant les premières estimations) 2 étalons sur des stories déjà réalisées par l’équipe et dont tous les membres maîtrisent la complexité. Tous les membres de l’équipe doivent se mettre d’accord pour définir ce qu’est :
- un story A de 2 points
- un story B de 5 points
par exemple
- la story « implémentation de page d’information utilisateur » est estimée à 2 points;
- la story « implémentation du tableau d’affichage des indicateurs » est estimée à 5 points
Avoir un seul étalon de 1 point n’est pas suffisant car il est difficile de savoir ce que représenteront des stories plus grandes. Avoir 2 stories étalons va permettre de mieux estimer car il est plus facile de faire des comparaisons entre plusieurs valeurs.
par exemple
- Je considère que cette story X est plus simple à réaliser que la story étalon A => alors elle est estimée à 1 point
- Je considère qu’elle est plus complexe que l'étalon A, mais plus simple que l'étalon B => alors elle est estimée à 3 points.
- Je considère qu’elle est plus complexe que l'étalon B => Alors elle est estimée à 8 points.
Une fonctionnalité ne doit pas être estimée à plus de 8 points. Si les membres de l'équipe estiment la story comme ayant plus de 8 points alors il faut découper la story en plusieurs moins complexes.
Petra propose également un point de vue intéressant sur l'étape de négociation des valeurs estimées. La négociation entre les membres ne se fait que si les estimations ont un écart important (sur l'échelle de fibonacci). Si l'écart est minime, alors, c'est la majorité qui l'emporte.
Par exemple, sur une équipe avec 3 membres Paul, Bill, John :
Si une story est estimée à 2 par Paul, 2 par Bill et 3 par John (je note 2-2-3) => l'écart entre l'estimation de John (3) et les estimations de Paul et Bill (2) étant minime, alors on considère l'estimation finale à 2 sans négociation des membres. l'estimation 2 étant majoritaire.
idem, si on a le cas 3-3-2 => l'estimation sera alors de 3.
Si on a 3-3-8 (ou 1-1-3), alors on négocie car l'écart est important. Mais, pour éviter que la négociation soit trop longue, les membres de l'équipes vont d'abord poser des questions fermées permettant de mieux comprendre le périmètre la story avant de se mettre d'accord sur une estimation finale.
par exemple, "Est-ce que le bouton valider doit être implémenté dans cette story ?", "Doit on prendre en compte les calculs de taux dans cette story ?"
S'il n'y toujours pas consensus à la suite des questions fermées, alors, on pourra envisager des négociations ouvertes.
La prise en compte de points abstraits n'étant pas naturelle (puisque sans unité) son utilisation ne sera pas forcément efficace dès les premiers sprints. Mais normalement, après 3-4 sprints, tous les membres devraient mieux appréhender son utilisation.
Il ne reste plus qu'à essayer de mettre en place cette solution. Je reste ouvert si vous avez d'autres solutions / façons de faire !
