Estimations

Les estimations agiles

Déjà, pourquoi ne pas estimer en hommes*jour ?… PARCE QUE !!!
Allez, on lit cet excellent article, et on passe à la suite 🙂 : La malédiction du jour homme

Bon. maintenant que ça c’est fait, du coup, comment on fait des estimations agiles ?

En général dans les équipes agiles on a besoin d’estimer deux choses :

• la valeur business d’un item
• la complexité technique d’un item

La priorité d’un item est déduite de ces deux estimations.

NB : Je vois souvent la notion de priorité confondue avec la notion de valeur business (j’ai entendu « priorité business »). Pour moi ce n’est pas une bonne pratique et c’est symptomatique d’un product owner qui priorise son backlog seul (sans impliquer l’équipe de réalisation). Bref. Fin de la disgression.

On veut des estimations simples, rapides, relatives.

Si je prends la pomme dans une main, ce serait compliqué d’estimer combien de grammes elle pèse. Même chose pour l’orange. Mais si je prends la pomme dans une main et l’orange dans l’autre, c’est assez facile de dire laquelle est la plus lourde… Et c’est tout ce que j’ai besoin de savoir pour prioriser !

J’ai essayé de lister ici différentes techniques… Est-ce que vous en connaissez d’autres ?

T-shirt sizes

Cette technique peut être utilisé pour les estimations de complexité comme pour les estimations de valeur. Mais concrètement je ne l’ai utilisé que pour les complexités techniques.

C’est très simple, très connu. Concrètement pendant un workshop je divise un paperboard en 6 parties.

• XS
• X
• M
• L
• XL
• NSP

Point de vigilance : essayer d’avoir une vraie répartition des items, pas tout en M…

Estimation line

Cette technique peut être utilisé pour les estimations de complexité comme pour les estimations de valeur (et je l’ai déjà utilisée dans les deux cas ^^).

Sur une grande table ou sur un mur : demander aux participants de simplement classer les items (epics / features / user stories) du plus simple au plus complexe (ou du moins de valeur au plus de valeur).

Interdit d’en mettre deux au même niveau ! (vous allez voir, c’est toujours difficile ^^)

On se met ensuite d’accord sur où placer les limites entre des groupes d’items et on fait la correspondance avec Fibonacci (ou des T-shirt size). Et hop, emballé c’est pesé, voilà une manière très rapide d’estimer 🙂

Buy a feature

Cet atelier peut permettre d’estimer rapidement la valeur business des features.

Pour le détail du déroulé : GIYF 🙂
… Notamment cet article avec plein de déclinaisons possibles de l’atelier : http://blog.xebia.fr/2014/08/20/les-differents-usages-de-buy-a-feature/

Quand on utilise une atelier « buy a feature » pour estimer des valeurs business, la question à poser aux participants est : « Imaginez que vous êtes tel ou tel client. Combien seriez-vous payer pour avoir cette fonctionnalité ? »

C’est mieux si on a fait des personae avant, on peut demander aux participants d’essayer de les incarner lors de cet atelier.

Complexity / value matrix

Si on veut aller encore plus vite sur les estimations (en comme il ne s’agit pas d’une session de backlog grooming mais bien d’un workshop d’initialisation, je pense que c’est tout à fait acceptable), on peut utiliser une matrice complexité / valeur.
Personnellement, je trouve cet atelier très efficace et je crois que c’est l’option que je retiens le plus souvent.

Pour le détail du déroulé : GIYF 🙂

Quand je l’anime, je suis assez stricte sur les règles :

• d’abord le PO (ou équivalent) présente l’item
• ensuite le PO, représentant marketing ou représentants clients  (premier groupe) le placent en hauteur dans la matrice
• ensuite l’équipe de réalisation (deuxième groupe) le placent à gauche ou à droite.
• s’il y a discussion / débat, j’ai toujours ces deux règles :
  • le premier groupe ne peut déplacer les post-its que verticalement
  • le deuxième groupe ne peut déplacer les post-its que horizontalement

Planning poker

Bien sûr, il y a le classique planning poker. Il peut être utilisé pour tous type d’estimations, complexité technique, valeur business…

Pour le détail du déroulé : GIYF 🙂

Il se différencie des techniques ci-dessus car il est plus long, amène des discussion et des débats beaucoup plus riches. De ce fait, je préfère ne pas l’utiliser à l’initialisation d’un backlog (quand on a vraiment beaucoup d’items à estimer), mais plutôt en backlog grooming quand il y a peu d’estimations à faire et qu’on veut aller plus dans le détail. En général on a estimé et priorisé le backlog grosse maille avec les autres techniques, et on « n’investit » dans un planning poker que pour les user stories complexes (on a besoin de discuter pour aligner nos vision sur le quoi et le comment), et/ou les user stories très court terme (pour le(s) prochain(s) sprint(s)).

Conseil : prévoir de quoi noter les choix techniques ou les précisions fonctionnelles qui émergent des discussions sur planning poker.

Point de vigilance : le planning poker implique une obligation de converger vers une estimation unique. Ne pas oublier le risque d’incertitude (notamment quand il y a divergence importante entre les estimations initiales).