home Dev.Pizza

Comment je calcule mes points de sprint

Ma vie de développeur web freelance
Pleins de formules mathématiques les unes au dessus des autres

Le sujet des points de sprint est un sujet très intéressant. Ces points nous permettent, à nous développeurs, de quantifier au mieux les différentes tâches qui nous sont attribuées + estimer la date de livraison la plus juste auprès de nos clients, collaborateurs, product owners, dirigeants et toutes autres personnes en relation avec les projets.

Niveau methodo, j’ai connu des tonnes de façons de faire et aujourd’hui je vais partager avec toi celle que je trouve aujourd’hui la meilleure. En tout cas, celle qui me réussit le mieux.

Utiliser la suite de Fibonacci

Classique.

Pour estimer un ticket, j’utilise la suite de Fibonacci et je m’arrête à 21. Perso je n’utilise jamais le chiffre 0, ni le chiffre 1. Entrer dans ce niveau de détail ne sert pas à grand chose.

Donc chez moi, un ticket pourra être estimé avec cette suite de valeurs : 2, 3, 5, 8, 13, 21.

Faire la moyenne des estimations de l’équipe

Lors des sprint plannings en équipe, ce qui marche plutôt bien lors de l’estimation d’un ticket, c’est de faire la moyenne des points proposés par chaque développeur.

Illustrons ça avec un exemple

Prenons une équipe de 4 devs qui doit estimer un ticket. Parmi les 4, trois devs estiment le ticket à 13 points et le quatrième l’estime à 8 points car il est plus confiant que les autres et n’hésites pas à expliquer son choix par des arguments intéressants.

Sans pour autant abandonner leur idée de départ, les trois développeurs ayant mis le plus de points vont attribuer au 4ème dev une part de confiance et vont donc accepter presque naturellement de diminuer l’estimation.

Ils vont donc faire le total et diviser le tout par le nombre de développeurs.

( 13 + 13 + 13 + 8) / 4 = 11,75

Ici le résultat donne 11,75. Ensuite un arbitrage sera fait pour arriver à un chiffre rond. En règle générale, soit on décide de se challenger et on passe à 11, ou soit on se la joue « secure » et on le laisse à 12.

Cette décision sera prise de manière collective et peut-être revue à la fin du sprint planning quand tous les tickets seront estimés.

Ici on ne parle plus de suite de Fibonacci. Cette suite ne servira qu’a titre individuel.

Comment calculer ses points?

Voilà le moment le plus intéressant. Comment je fais aujourd’hui pour calculer les points d’un ticket? Je vais te le dire. Mais sache juste, que pour l’instant je n’inclue pas du tout le facteur « temps ». De ça, on va en parler juste après.

Alors…

Un ticket de sprint, je le compose en 5 grands thèmes distincts :

  1. L’analyse : ici je vais estimer si l’analyse du ticket est longue et complexe. Pour certains tickets, il n’y a rien à analyser. Pour d’autres, il faut faire des recherches assez approfondies avant de passer à la conception.
  2. La conception : ici je vais mettre en place le concept des devs. CAD, établir l’architecture, les modèles de données, les méthodes à mettre en place…etc. La conception peut être plus ou moins complexe à définir.
  3. La réalisation : ici c’est simple… on fait! On réalise le ticket. On met en place les archis, les migrations, les updates et on code, on code, on code!
  4. Dialogues : ce point concerne les besoins de dialogues qu’on va devoir entreprendre avec nos collaborateurs. Ici on va devoir se faire une idée du volume d’échanges qu’on va devoir avoir avec telle ou telle personne, de tel ou tel service, avec potentiellement des phases de validations ou pas. Est-ce que ce sera dur d’entrer en contact? Est-ce que ce sera long d’avoir les réponses? Faudra-t-il prévoir des réunions?
  5. Tests : et enfin, on va finir par les tests. Ce point couvre tout ce qui a attrait à la phase de recette jusqu’à la validation finale qui permettra de passer à la mise en prod.

Chacun de ces grands thèmes comporte 10 points.

L’idée est de pouvoir estimer une note sur 10 pour chacun des thèmes et en faire un total à la fin. La note totale ne peut donc pas excéder 50 points.

Ensuite on divise le tout par 2,38 et on obtient une note finale sur 21. Pour finir, on va choisir le nombre de la suite de Fibonacci qui se rapproche le plus de notre note calculée.

Je vais illustrer ça avec un exemple

Admettons, je suis en train d’estimer un ticket. Et les notes que je vais attribuer à chaque thème sont les suivantes :

  • Analyse : 5 points (normal)
  • Conception : 5 points (normal)
  • Réalisation : 10 points (ça va être chaud)
  • Dialogue : 8 points (il y a du taff)
  • Tests : 5 points (normal)

Ce qui nous donne un total de 33 points! Schématiquement ça donne un truc comme ça.

Diagramme en étoile des différents thèmes d'un ticket

PS : ce diagramme est conçu avec chart.js. Si tu veux te servir de ce diagramme pour tes projets, je t’ai laissé un petit bout de code ici.

Si on divise le tout par 2,38 on obtient 13,86. Le chiffre le plus près dans la suite Fibonacci est 13. C’est parfait!

Je vais donc estimer mon ticket à 13 points et faire ma proposition au reste de l’équipe.

Comment calculer la vélocité?

Ou en gros, comment embarquer le facteur « temps » dans l’estimation des sprints? Plus précisément, comment savoir combien de points allons-nous pouvoir produire par jour en moyenne?

Pour ça, il est nécessaire de faire un premier sprint de test et de voir combien de points max on aura pu réaliser. Ce résultat sera la base pour les sprints suivants. Et à chaque nouvelle itération de sprint, on réajuste le tir.

Je dirais que niveau estimation de temps/vélocité, on commence à être au point à la fin du 3ème sprint.

Perso, aujourd’hui j’arrive à killer 4 points par jour. Parfois plus, parfois moins. Mais en moyenne c’est 4. Et les délais auxquels je m’engage auprès de mes clients sont plutôt bien respectés.

4 points par jour, c’est ma vitesse de croisière.

Le chiffre 4 est aussi un bon chiffre. Ça fait 2 pour le matin et 2 pour l’après-midi. Avec ce chiffre on s’y retrouve bien. Du coup quand j’ai un gros ticket à 21, je sais que ça me prendra environ une semaine.

Voilà comment je fais pour calculer mes points.

« Exit » les tickets à plus de 21 points!

Si un ticket fait plus de 21 points (donc plus d’une semaine de taff), je ne le prends pas tel quel. Si j’estime qu’une feature me prends plus de 5 jours à développer, je fais le nécessaire pour la splitter en étapes.

Par expérience, un ticket à 21 points est déjà assez conséquent. Et le réaliser en une semaine reste déjà un gros défi. On a beaucoup plus de chances de tomber sur des embûches qu’un ticket à 4 points.

Hop, hop, hop, on découpe tout ça et on en fait des sous-tickets. C’est plus organisé et il y a moins de risques d’entrer dans un fucking cycle en V qui fait chier tout le monde (mon instant poésie 😆).

Voilà voilà.

Maintenant tu sais comment je calcule mes points de sprint. Comme je te disais en début d’article, depuis que je fais du dev, des méthodes j’en ai essayé des tas. Et chez moi, c’est celle-ci qui marche le mieux. Du moins pour l’instant.

Et je voulais partager ça avec toi! 🙂

Mais peut-être que je passe à côté d’une méthode du futur encore mieux! Si t’en a une, je suis preneur 😁 .

1 commentaires :
  • De Baptiste

    Je ne connaissais pas du tout cette méthode, plutôt cool 🙂
    Merci pour l’article !

Laisser un commentaire