Calculer la somme des points d’effort autorisés

Ecrit par << Paquet Judicaël >>

Une question qui revient souvent dans les projets en Scrum est de savoir comment calculer le nombre de points d’effort que peuvent prendre les développeurs pendant un Sprint. On appellera cela « somme des points d’effort autorisés ».

Nous allons voir une méthode dans cet article qui fonctionne vraiment bien et qui permet de faire de bonnes estimations de façon générale.

L’idéal de l’agiliste est de travailler en #NoEstimate (ne pas estimer les tâches) mais rare sont les entreprises capables à ce jour d’accepter ce principe très Agile.

Les 3 premiers Sprint du projet

Lors des 3 premiers Sprint, on considèrera qu’on est pas encore assez avancé pour calculer automatiquement la somme des points d’effort autorisés. Le Product Owner va alors laisser les développeurs choisir celle-ci.

Le résultat de la vélocité de ces 3 premiers sprints ne sera pas forcément très fiable et constant ; on estime qu’il faut 3 sprint pour commencer à avoir une base exploitable.

Nous allons vraiment rentrer dans le vif du sujet dès les Sprint suivants.

Les sprints suivants

Il existe une méthode efficace pour calculer la somme des points d’effort autorisés d’un Sprint d’une équipe.

Formule

Voici la formule magique qui va grandement vous aider et que nous allons expliquer en détail :

Co = ∑(V3) / ∑(Ca) * Cae

Voici l’explication de chaque partie pour effectuer le calcul :

∑(V3) : somme des points d’effort réels des user-stories qui sont en « Done » dans les 3 précédents Sprint

∑(Ca) : somme des jours/homme de présence des développeurs de l’équipe dans les 3 précédents Sprint

Cae : nombre de jour/homme estimé sur le prochain Sprint

Pour faire relativement simple, nous calculons le nombre de points d’effort que peuvent faire les développeurs sur le prochain Sprint par rapport au nombre de jours travaillés qu’ils auront.

Exemple pour comprendre

Tout le monde n’a pas l’âme d’un mathématicien bien que les formules ne soient pas très complexes mais voilà un cas concret pour bien comprendre la formule.

Mon équipe A vient de terminer le Sprint 3 et le Scrum Master doit indiquer que Product Owner, la somme totale des points d’effort qu’il pourra s’autoriser dans le prochain Sprint (Sprint 4).

Le Scrum Master a recensé ces chiffres dans un tableau :

Vélocité fin de sprint               nombre de jour/homme travaillé

Sprint 1                            45                                                        30
Sprint 2                           34                                                         27
Sprint 3                           50                                                        29

Il a également noté que l’équipe travaillera 28 jours sur le Sprint 4 si il n’y a pas d’absence en cours de Sprint non prévue à ce jour.

Il va ainsi faire son calcul :

∑(V3) = 45 + 34 + 50 = 129
∑(Ca) = 30 + 27 + 29 = 86
Cae = 28

Donc

Co = 129 / 86 * 28 = 42

Le Scrum Master vient de déterminer que le Product Owner pourra proposer des user-stories qui au total feront 42 en points d’effort.

Sachant qu’il n’est pas toujours possible de tomber pile poil sur 42, le Product Owner pourra évidement proposer 43, 42 ou 41 en points d’effort global.

Si mon Sprint est terminé ?

Sachant que cela reste dans l’estimation, il est possible que les développeurs finissent un Sprint en avance (le PO a tout validé et toutes les user-story sont en Done).

Il existe de nombreuses solutions sur ce sujet comme les deux cas suivants les plus utilisés :

  • Le Product Owner pourra ajouter des petites user-stories afin de ne pas laisser les développeurs sans travail.
  • On autorisera les développeurs à profiter du temps restant pour faire de la recherche (Spike). Il sera par contre indispensable d’enlever ce temps à la capacité du Sprint. Voici un article pour bien comprendre le Spike : lire l’article.

/!\ Les mathématiciens comprendront vite ce type de règles : si on ne permet pas d’avoir proportionnellement  plus de point d’effort qu’avant, le nombre de points d’effort autorisées finira toujours par descendre.

Et si une user-story est ré-estimée ?

Quand une user-story n’est pas terminé dans un Sprint, on la remet dans le Sprint suivant en la réestimant car son point d’effort est en toute logique diminuée (dans de rares cas augmentées).

Nous allons dans ce cas appliquer la nouveau point d’effort pour la somme des points d’effort autorisées (et celle prise en charge dans le Burndown Chart), mais nous prendrons le point d’effort le plus haut mis à user-story dans la somme des points d’effort réelles pour le calcul.

Par exemple, si une user-story sur le Sprint 2 avait un point d’effort de 8 et que les développeurs estiment en début de Sprint 3 qu’elle a à présent une complexité de 5 :

  • On prendra 5 comme point d’effort pour la somme des points d’effort autorisés du Sprint (et pour le Burndown Chart)
  • On prendra 8 comme point d’effort pour la vélocité de fin de Sprint.

Le mieux c’est de bien le montrer sur le post’it (voire le logiciel) :

réestimer une complexité
réestimer un point d’effort

Cela n’est peut-être pas très clair, mais il est essentiel de prendre le chiffre le plus haut afin d’avoir des calculs au plus juste.

Déterminer la capacité

Il est fortement conseillé de proposer un calendrier de présence affiché au mur qui permet d’afficher les absences de chaque membre de l’équipe sur le projet.  Cela sera d’une grande aide au Scrum Master pour calculer cette capacité.

Voici un exemple :

capacité des équipe
capacité des équipe

On privilégie de ne dessiner que les absences car il y a beaucoup plus de chance d’ajouter des absences que d’en enlever. Du coup les développeurs iront dessiner leurs absences directement sur le mur (sur cet affichage).

La base des roadmap

Sachez que grâce à cette méthode, vous pourrez aller jusqu’à créer des roadmap fiables sur vos projets ; ces roadmap sont souvent attendues par les direction qui n’ont pas encore pu s’aiguiser intégralement.

Attention au contexte

Si cette méthode est utile, il faut faire attention aux contexte de l’entreprise. Cette méthode ne doit pas amener un chef de projet à utiliser cette méthode pour comparer des jours/homme et des point d’effort.

Le Scrum Master devra être le gardien contre ce type de comparaisons et envisager d’autres méthodes de prédictibilité si le chef de projet ne veut pas changer cette mauvaise pratique.

4 réponses sur “Calculer la somme des points d’effort autorisés”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *