--- title: "Capacité de sprint" module: projects type: functional status: active updated: 2026-09-01 --- # Capacité de sprint > Doc fonctionnelle : décrit le **quoi** et le **pourquoi** (point de vue utilisateur / chef de projet). ## À quoi ça sert 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. ## Où ça se trouve 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. ## Comment ça se lit 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 : - **Capacité** : un segment **vert** pour ce qui reste disponible, puis un segment par catégorie, à sa couleur. Le vert est réservé au disponible ; il n'est pas proposé pour une catégorie, pour qu'aucune déduction ne puisse lui ressembler. - **Charge** : la part qui **tient dans la capacité** (indigo) et, le cas échéant, la part **à sortir du sprint** (rouge). La coupure se fait exactement à hauteur de la capacité nette. 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. ### Quand le sprint ne tient pas 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. ### Deux avertissements qui comptent - **« N items sans difficulté saisie »** — ces items ne sont pas comptés dans la charge. Quand ce nombre est élevé, la comparaison ne veut rien dire : cotez avant de conclure. - **« Capacité éloignée de plus de 20 % de l'historique »** — le sprint est calé très loin de ce que le projet livre d'habitude. Dans ce cas, c'est presque toujours le modèle de capacité qui a tort, pas l'historique. ## Comment ça se remplit ### 1. Les acteurs 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. ### 2. Les jours | 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. ### 3. Les catégories 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é. ## Ce que chacun porte déjà 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 report d'un sprint à l'autre 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. ## Conversion points ↔ jours 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](backlog-effort-scale.md) 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). ## Ce que cet écran ne fait pas - **Pas de comparaison par personne.** L'alerte se juge sur le total de l'équipe. Une capacité nominative devient fausse dès la première réaffectation en cours de sprint, qui est le cas normal. Le détail par personne sert à la saisie, pas au verdict. - **Pas de suivi du temps réellement passé.** Aucun lien n'existe entre les temps saisis et un item de backlog. La comparaison porte sur des estimations, pas sur du réalisé. - **Pas de capacité par activité ou par rôle.** Un même acteur ne peut pas déclarer « 3 j de dev et 2 j de test ». - **Pas de prévision multi-sprints.** L'écran regarde un sprint à la fois. ## Retirer un acteur 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. ## Points d'attention - **Sans dates de début et de fin, aucun calcul.** Un sprint sans bornes affiche un message explicite plutôt qu'un chiffre faux. Les dates se saisissent sur la fiche du sprint (onglet *Planning* du projet). - **L'historique démarre au 25/08/2026**, date de ré-ancrage de l'échelle d'effort. Les sprints antérieurs valent environ trois fois plus de points pour le même travail : les inclure donnerait une moyenne absurde. L'encart historique reste donc vide tant que trois sprints n'ont pas été clos après cette date. - **La reprise automatique des absences suppose que le compte utilise le planning.** Sinon la colonne reste à zéro et se remplit à la main — l'écran fonctionne à l'identique. ## Voir aussi - Doc technique : `../../.claude/technical-docs/projects/sprint-capacity.md` - [Échelle d'effort du backlog](backlog-effort-scale.md) - [Filtres du backlog](backlog-filters.md)