Doc fonctionnelle : décrit le quoi et le pourquoi (point de vue utilisateur / chef de projet).
Avant de démarrer un sprint, savoir si ce qu'on y a mis tient dans le temps réellement disponible de ceux qui vont le faire.
Jusqu'ici, un sprint n'avait qu'une somme de points. Rien ne disait combien de jours l'équipe avait devant elle, ni combien de ces jours partaient en réunions, en support ou en recette. Le sous-onglet Capacité du backlog répond à cette question.
Onglet Backlog d'un projet → sous-onglet Capacité, à côté de Statistiques.
L'onglet est masquable projet par projet (paramètres du projet → Backlog → Capacité), pour les projets qui ne fonctionnent pas en sprints.
Un sélecteur Jours / Points en haut de l'écran pilote toutes les valeurs affichées, et le choix est mémorisé. La saisie, elle, reste toujours en jours : une disponibilité exprimée en points d'effort n'aurait aucun sens à remplir.
Quatre chiffres en tête :
| Chiffre | Ce qu'il dit |
|---|---|
| Capacité brute | Jours ouvrés du sprint, absences déduites, pour tous les acteurs |
| Capacité nette | Ce qui reste après les catégories (réunions, support…). Le pourcentage affiché à côté est le focus factor |
| Charge estimée | Somme des cotations des items du sprint, convertie en jours |
| Reste à placer / Dépassement | L'écart, avec un signal binaire : le sprint tient, ou il ne tient pas |
En dessous, deux barres sur la même échelle — c'est ce qui permet de comparer leurs longueurs :
Chaque barre a sa légende chiffrée en dessous. Le fond gris clair au bout de la barre la plus courte n'est pas une valeur : c'est l'espace restant sur l'échelle commune, dont le total est rappelé dans la légende.
Un bouton « Que sortir du sprint ? » apparaît. Il propose les items à retirer — les moins prioritaires d'abord, et à priorité égale les plus gros, pour y arriver en moins de cartes. La sélection est pré-cochée jusqu'à combler le dépassement et reste entièrement modifiable ; le solde se recalcule à chaque coche. Un bouton déplace le tout vers le sprint suivant, ou détache les items si aucun sprint postérieur n'est daté.
Les items en cours ne sont jamais proposés : sortir du sprint ce que quelqu'un est en train de faire est du gâchis. Ils restent comptés dans la charge.
La suggestion ignore les dépendances entre items et les engagements pris auprès d'un client. Elle fait gagner le tri, pas la décision — d'où la sélection modifiable.
On ajoute au sprint les personnes qui vont réellement travailler dessus. Tous les membres du projet n'en font pas partie : un sponsor ou un DPO a un rôle sur le projet sans consommer de capacité de développement.
Le rôle projet de chacun est rappelé à côté de son nom.
Un raccourci « Reprendre les assignés du sprint » compose l'équipe à partir des personnes déjà affectées aux items — l'information est dans le backlog, autant l'utiliser. Les assignés qui ne sont pas membres du projet sont écartés, et leur nombre annoncé.
La grille se remplit librement, puis un bouton Enregistrer en haut du tableau écrit tout d'un coup et confirme par une notification. Les actions de ligne (rétablir les jours ouvrés, reprendre les absences du planning, retirer un acteur) enregistrent au passage ce qui est saisi, pour ne rien perdre.
| Colonne | D'où elle vient | Modifiable |
|---|---|---|
| Jours ouvrés | Calculés depuis les dates du sprint : week-ends et jours fériés retirés | Oui, une valeur forcée peut être rétablie d'un clic |
| Absences | Reprises automatiquement du planning (congés, RTT, maladie…) si le compte saisit ses temps | Oui — la ligne bascule alors en saisie manuelle, réversible |
Toutes les catégories de congés et d'absence du planning sont retenues — congés, RTT, maladie, récupération, école, temps partiel, autre motif. En revanche les temps internes (formation interne, réunions d'équipe) ne le sont pas : ils relèvent des catégories de déduction ci-dessous, les compter deux fois fausserait le calcul.
Ce sont les activités qui mangent du temps de sprint sans produire d'item de backlog. Trois sont créées d'office au tout premier accès du compte — et seulement à ce moment-là : si vous les supprimez toutes parce que rien de tout cela ne vous concerne, elles ne reviennent pas.
| Catégorie | Défaut | Ce que ça couvre |
|---|---|---|
| Cérémonies | 0,5 j | Planning, revue, rétrospective, points quotidiens |
| Support | 1,5 j | Interruptions, demandes urgentes, astreinte |
| Recette / tests | 0 j | À activer si la recette est portée par l'équipe de dev |
Elles se configurent au niveau du compte (bouton Configurer les catégories), pas du projet : la façon dont le temps se répartit est une propriété du métier, pas d'un projet particulier. Le bouton n'est offert qu'à qui peut modifier le projet depuis lequel il est ouvert.
La valeur par défaut est pré-appliquée au moment où l'acteur est ajouté à un sprint, puis ajustable ligne par ligne. Changer un défaut, ou ajouter une catégorie, ne retouche donc aucun sprint déjà composé — y compris clos : seuls les acteurs ajoutés ensuite en héritent. Sur les sprints existants, une catégorie nouvelle démarre à zéro et se remplit à la main.
Six catégories au maximum. Ce n'est pas une limite technique : au-delà, une grille de déductions cesse d'être remplie sérieusement et se remplit au doigt mouillé.
Face au net dev de chaque personne, la grille affiche la charge des items du sprint qui lui sont déjà attribués. Aucune couleur, aucun verdict : le dépassement continue de se juger sur le total de l'équipe. C'est là pour révéler qu'une personne porte 9 j de cartes pour 6 j disponibles pendant qu'une autre en a 2.
Un item porté par deux personnes compte en entier chez chacune — toutes deux sont concernées par la totalité de la carte. La colonne ne se totalise donc pas. En revanche, le pied du tableau affiche la charge sans porteur, souvent le chiffre le plus parlant : c'est le travail que personne ne s'est encore attribué.
Le bouton Reprendre le sprint précédent recopie la composition de l'équipe et les déductions.
Les absences ne sont volontairement pas reportées. C'est l'erreur d'usage la plus répandue des outils du marché : au sprint suivant, plus personne n'est en congé, la capacité affichée est fausse par excès, et l'équipe cesse d'y croire. Un message le rappelle à chaque copie.
Par défaut, un point d'effort vaut 2 heures et une journée 7 heures — soit 3,5 points par jour. Ce rapport découle de l'échelle d'effort et tombe dans les huit fourchettes qu'elle annonce (3 points ≈ 0,86 j pour « ~1 j », 21 points = 6 j pour « 5-6 j »).
Les deux valeurs sont réglables par compte (bouton Configurer les catégories) : tout le monde ne travaille pas 7 heures par jour, et une équipe peut avoir mesuré son propre rapport.
D'ailleurs l'écran le mesure pour vous. Pour chaque sprint clos disposant d'une capacité renseignée,
il calcule capacité nette ÷ points livrés et signale l'écart :
Sur vos 3 derniers sprints, un point vous a coûté en moyenne 2,7 h — vous êtes configuré à 2 h.
Avec un bouton pour adopter la valeur. Rien ne change tout seul, et la suggestion n'apparaît qu'au-delà d'un quart d'heure d'écart. Attention à ce qu'elle mesure : la capacité nette est le temps disponible, pas le temps effectivement passé — c'est donc un majorant, utile pour caler la planification, pas pour de la comptabilité.
La conversion est brute : elle ne retranche aucun temps non productif, puisque c'est précisément le rôle des catégories. Le « 14 à 16 points par semaine » de l'échelle d'effort décrit au contraire une capacité déjà nette (4 jours nets × 3,5 = 14).
Retirer quelqu'un du sprint l'enlève de la grille, mais sa saisie est archivée, pas détruite : si on le réintègre plus tard, la ligne est restaurée. Ses jours repartent en revanche des valeurs par défaut — retirer un acteur signifie qu'on a défait cette composition d'équipe, la remettre en place est une nouvelle décision.
../../.claude/technical-docs/projects/sprint-capacity.md