Pratiques pour un chiffrage réussi

Plus on devient bon dans l’agilité, la démarche produit et le découpage des user stories, moins on va avoir besoin de chiffrer. Mais en attendant, la plupart des équipes font des chiffrages, alors autant faire ça bien.

Bien comprendre le chiffrage

On vous donne un paquet de cartes, on vous dit qu’il faut chiffrer en points plutôt qu’en jours/homme et c’est parti. Sauf qu’on a oublié de vous parler de quelques trucs.

Chiffrage par comparaison

Le secret du chiffrage efficace, c’est la comparaison.

Je serais bien incapable de donner la distance exacte en km qu’il faudrait parcourir pour aller  de Paris à Lille ou de Strasbourg à Montpellier, et donc le temps que ça me prendrait. Il y a plein d’inconnues, de variabilité. Ça prendrait plus de temps de déterminer cette distance que de la parcourir.

Par contre, très facilement je peux dire que Strasbourg-Montpellier c’est grosso modo 3 fois Paris-Lille.

Paris-Lille c’est aussi plus ou moins équivalent à Bordeaux-Toulouse. Si je sais que Bordeaux-Toulouse je le fais en 2 à 3h, alors je peux estimer très facilement Paris-Lille.

C’est pareil pour vos stories : chiffrer en isolation ça prend du temps pour un résultat pas meilleur. En les comparant, ce n’est plus qu’une formalité.

Du coup, note pour les POs : quand le chiffrage d’une story vous parait trop élevé, au lieu de demander de le baisser, faites des comparaisons : “La story d’avant vous avez mis 5, celle là ne me paraît pas plus compliquée pourtant vous avez mis 13, pourquoi ?”.

Plus c’est gros, plus c’est flou

On utilise la suite de Fibonacci pour mettre en avant l’incertitude due à la variabilité croissante. Plus les stories sont grosses, moins le chiffrage est correct.

En général, vous allez pouvoir corréler la taille et le temps passé pour les stories les plus petites (1, 2, 3) mais au delà, la variabilité fait que vous ne pourrez pas les distinguer.

C’est aussi une erreur de croire qu’une story à 13 vaut 13 story à 1. On a tendance à faire des réduction sur le volume quand on chiffre :

Dans un de mes projets on devait faire une story qui consistait à développer 100 validateurs. Les validateurs étaient simples. Si chacun avait été sa propre story, on aurait eu 100 stories à 1 point. Mais comme tout était dans une seule story, personne ne voulait la chiffrer à 100. Je crois qu’elle a fini à 21. Est ce que vous pensez que grâce au discount ça a pris moins de temps ?

Du coup, faire la somme de vos points de stories n’a aucun sens si elles sont trop grosses, votre vélocité sera en dents de scie.

Vous devez apprendre collectivement, au fur et à mesure, à faire des stories plus petites. Ne laissez jamais s’installer l’idée que “oui mais ça n’a pas de sens de découper, tant pis elle fera 21”. Vous ne savez pas encore comment faire, mais il y a toujours des pistes.

Bien faire le chiffrage

L’échelle

C’est l’arme secrète du chiffreur : maintenant que vous avez compris qu’en comparant des stories le chiffrage devenait plus facile, vous devinez qu’avec une échelle de référence, tous vos chiffrages seront beaucoup plus rapide et pas moins précis qu’avant.

Pensez à mettre à jour vos références régulièrement, pour ne pas se retrouver avec des stories vieilles de 2 ans datant de quand la moitié de l’équipe n’était pas encore arrivée.

Introducing : Xtreme Quotation

Pour constituer la première version de l’échelle, j’ai légèrement modifié un atelier créé par Jonathan Scher et Guillaume Duquesnay appelé l’Xtreme Quotation.

L’atelier dure 30 à 45 minutes.

Vous aurez besoin d’imprimer entre 60 et 100 stories sur des petits papiers (de la taille d’une carte). Prenez des stories que l’équipe connait, sinon la discussion portera sur le contenu plutôt que le chiffrage. Idéalement, prenez les 100 dernières stories que l’équipe a réalisé.

L’équipe, organisée en petits groupes de 4-5 personnes maximum, va faire plusieurs passes sur les stories en les comparant :

1. Faites trois tas : les petites, moyennes et grosses stories.
2. Prenez le tas des petites stories, et répartissez à nouveau entre Petit- et Petit+. Faites pareil pour les deux autres tas.
3. Pour chaque tas, regardez si les stories sont homogènes entre elles ou si elles appartiennent finalement à un autre tas.
4. Ensuite, pour chaque tas, il faut élire une story de référence, qui représente parfaitement pour tout le monde sa taille.
5. Faites une dernière passe en comparant les stories de chaque tas avec leur story de référence. Changez les de tas si besoin.

Vous avez maintenant 6 tas de stories, auxquels il va falloir attribuer une valeur. Prenez la story de référence la plus petite et comparez la à une tâche très simple, comme changer la couleur d’un cadre ou corriger une faute d’orthographe. Si les stories sont équivalentes, alors la plus petite taille vaut 1. Sinon commencez à 2.

Pour finir, il faut poser une limite sur la taille maximum que vous acceptez avant d’imposer le redécoupage de la story.

Voilà, vous avez une échelle de chiffrage et un moyen simple de voir si les stories sont trop grosses.

---

Bonus : chiffrer les bugs ou pas ?

Les bugs sont par définition des inconnues, dont la variabilité est infinie. Ce qui veut dire que vos chiffrages seront extra faux. Alors est ce que ça vaut le coup ?

Oui et non.

Quand on priorise les sujets pour un sprint, on aura trois tas :

• Ce dont on est sûrs à 100% de finir dans le sprint.
• Ce qu’on pense pouvoir faire rentrer si tout se passe bien.
• Ce dont on est sûrs à 100% de ne pas faire dans le sprint.

Donc pour le PO, c’est important d’avoir une idée, même vague, du temps que peuvent prendre les bugs pour savoir ce qu’on peut mettre dans la première partie.

Par contre, attribuer des points à des bugs et les ajouter dans le calcul de la vélocité est une erreur :  en corrigeant des bugs, vous n’avez pas fait avancer le projet, vous avez nettoyé ce que vous aviez raté lors d’un précédent sprint.

En disant que vous avez fait un sprint à 50 points avec que des stories, ou un sprint à 50 points avec la moitié de bugs, on a l’impression que c’est pareil alors qu’en réalité votre vélocité est divisée par 2 dans le deuxième cas.

Autrement dit, si vous faisiez moins de bugs vous iriez beaucoup plus vite, et c’est ça qu’on montre quand on n’ajoute pas les points de bugs dans le calcul de la vélocité.

Donc mon conseil :

1. Estimez la taille des bugs mais avec une autre échelle, pour faciliter le sprint planning
2. Ne les ajoutez surtout pas dans votre calcul de vélocité
3. Faites moins de bugs