Calculer la capacité d’un sprint

capacite d un sprint
capacite d un sprint

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 la « capacité ».

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 sprints du projet

Lors des 3 premiers sprints, on considèrera que nous ne sommes pas encore assez avancé pour calculer automatiquement la somme des points d’effort autorisés soit la capacité. Le product owner va 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 sprints 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 capacité de l’équipe d’un Sprint.

Formule capacité

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 sprints

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

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 au 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-stories 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 points d’effort qu’avant, le nombre de points d’effort autorisés finira toujours par descendre.

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

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

Nous allons dans ce cas appliquer la nouveau point d’effort pour la somme des points d’effort autorisés (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éels 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 un point d’effort 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 roadmaps fiables (restant estimatives) sur vos projets ; ces roadmaps sont souvent attendues par les directions 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 une personne tiers à 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 cette personne ne veut pas changer cette mauvaise pratique.

Mais ceux qui valident la capacité sont les développeurs

Cette méthode a pour but d’aider le product owner a connaitre la capacité estimative des prochains sprints. Cependant, c’est toujours les développeurs qui valideront ou non, leur capacité de faire sur un sprint.

Article : Laissez vos développeurs choisir leur capacité !

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

2 Commentaires

  1. « 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. »

    Mais si la story n’est pas terminée, tu ne la prends pas en compte dans le calcul de la vélocité ??

    • Dans la vélocité (somme des point d’effort totaux des demandes en Done en fin de sprint), on ne prendra les points d’effort que des demandes 100% terminées. En Scrum, on estime que seule une demande 100% terminée donne de la valeur donc seule la demande 100% terminée sera incluse dans la vélocité.

4 Rétroliens / Pings

  1. Top 10 des articles de mars 2017 | Blog Myagile Partner
  2. Faire une planning release en agile | Blog Myagile Partner
  3. Comment gérer les bugs en scrum ? | Blog Myagile Partner
  4. La Sprint Planning Meeting en Scrum | Blog Myagile Partner

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.