Calculateur capacité de sprint
Cinq personnes sur 10 jours ouvrés à 8 heures par jour avec un facteur de focus de 0,7 totalisent 400 heures brutes et 280 heures de capacité réelle ; les 120 autres partent en réunions et interruptions. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Effectif
- 5
- Jours ouvrés
- 10
- Heures par jour
- 8
- Facteur de concentration
- 0,7
- Jours-personne
- 50
- Heures brutes
- 400
- Heures de capacité
- 280
- Jours-personne de capacité
- 35
La capacité de sprint est la quantité réaliste de travail qu'une équipe peut s'engager à livrer dans une itération fixe, mesurée en heures après déduction des réunions, interruptions et disponibilité partielle. Les scrum masters, responsables d'ingénierie et leaders de livraison ont besoin d'une base arithmétique transparente avant d'intégrer des stories au tableau de sprint ou de comparer la charge planifiée à la vélocité historique. Ce calculateur de capacité de sprint d'équipe accepte l'effectif (ou des équivalents temps plein), les jours ouvrés du sprint, les heures nominales par personne et par jour, et un facteur de focus ou de disponibilité entre zéro et un ; il renvoie les heures brutes, les heures de capacité, les personne-jours, les personne-jours de capacité et les heures de surcharge, avec une courte chaîne de formule.
Ce que signifie la capacité de sprint et comment la formule fonctionne
Les équipes agiles disposent rarement de cent pour cent du temps calendaire pour les éléments de backlog engagés. Les jours fériés réduisent le nombre de jours ouvrés, les membres à temps partiel diminuent l'effectif effectif, et les réunions, la rotation de support et les changements de contexte consomment une fraction de chaque journée.
Le modèle standard de planification multiplie quatre leviers : combien de personnes (ou FTE) composent l'équipe, combien de jours ouvrés tombent dans la fenêtre du sprint, combien d'heures nominales chaque personne peut offrir par jour, et un facteur de focus ou de disponibilité qui ramène le temps nominal à la part réservée au travail de sprint. Les heures brutes valent effectif fois jours ouvrés fois heures par jour. Les heures de capacité valent heures brutes fois le facteur de focus.
Les personne-jours valent effectif fois jours ouvrés ; les personne-jours de capacité appliquent le même facteur de focus pour que vous puissiez planifier en unités de jours lorsque le tableau suit les stories en personne-jours plutôt qu'en heures. Les heures de surcharge sont l'écart entre brut et capacité — les réunions et le travail non planifié déjà retirés par le facteur de focus.
Exemple : cinq personnes, dix jours ouvrés, huit heures par jour et un facteur de focus de zéro virgule sept donnent quatre cents heures brutes et deux cent quatre-vingts heures de capacité, avec cent vingt heures de surcharge et trente-cinq personne-jours de capacité. Le calculateur ne remplace pas la prévision de vélocité en story points ; c'est le plafond budgétaire en heures contre lequel vous comparez le reste de travail estimé. Un effectif fractionnaire est autorisé pour les contributeurs à temps partiel (par exemple quatre virgule cinq FTE).
Le facteur de focus doit se situer entre zéro et un inclus : envoyez zéro virgule sept pour soixante-dix pour cent de focus, pas soixante-dix.
Où un calculateur de capacité de sprint d'équipe se justifie
Les scrum masters et coaches agiles utilisent un calculateur de capacité de sprint d'équipe lors de la planification de sprint pour fixer un budget d'heures transparent avant que l'équipe n'intègre des éléments du backlog, surtout lorsque l'effectif change en milieu de trimestre ou que les jours fériés grignotent une cadence de deux semaines.
Les responsables d'ingénierie comparent les heures de capacité entre squads pour équilibrer le staffing d'un train de release, et les product owners comprennent pourquoi une équipe plus petite ou partiellement disponible ne peut pas absorber le même engagement que le sprint précédent. Les outils PMO et de reporting de livraison automatisent la même formule dans des notebooks de portefeuille afin que chaque équipe stocke heures brutes, heures de capacité et surcharge côte à côte pour l'audit.
Les formations et plugins LMS ont besoin d'un oracle déterministe qui rejette un facteur de focus de soixante-dix ou un effectif nul au lieu d'émettre silencieusement un NaN qu'un correcteur buggé pourrait traiter comme un succès. Une validation échouée ne consomme pas le solde. Gardez les requêtes légères, figez les champs de capacité arrondis dans les tests, et vous obtenez des budgets de sprint reproductibles pour les cérémonies de planification, les edge workers et les contrôles CI sans déployer une pile complète de portefeuille de projets.
Cas d’usage
Budget d'heures à la planification de sprint
Calculez les heures de capacité à partir de la taille d'équipe, des jours ouvrés, des heures quotidiennes et du facteur de focus avant l'engagement des stories, pour que la charge planifiée reste dans un budget transparent.
Ajustements congés et temps partiel
Recalculez la capacité lorsque les jours fériés réduisent les jours ouvrés ou qu'un FTE fractionnaire diminue l'effectif, et affichez les heures de surcharge à côté des personne-jours de capacité ajustés.
Reporting portefeuille multi-équipes
Automatisez la même formule de capacité entre squads dans des notebooks ou outils de livraison pour que la finance et le PMO comparent heures brutes et heures ajustées au focus sur une seule piste d'audit.
Questions fréquentes
Qu'est-ce que le facteur de focus ?
Une fraction du temps nominal disponible pour le travail de sprint engagé après réunions, support et interruptions. Utilisez 0.7 pour 70 % de focus — pas 70. Les valeurs doivent être entre 0 et 1 inclus.
L'effectif peut-il être fractionnaire ?
Oui. Un headcount fractionnaire modélise des contributeurs à temps partiel ou un FTE partagé (par exemple 4.5). Le headcount doit rester strictement supérieur à zéro.
Cela remplace-t-il la vélocité en story points ?
Non. Les heures de capacité sont le plafond du budget temps. La vélocité en story points prévoit combien de backlog l'équipe termine habituellement ; utilisez les deux ensemble à la planification.
Comment calcule-t-on la capacité de sprint en heures ?
Multipliez l'effectif par les jours ouvrés, les heures par jour et le facteur de focus. Cinq personnes, 10 jours, 8 heures et 0,7 donnent 280 heures de capacité sur 400 heures brutes, soit 35 jours-personne de capacité.
Faut-il saisir 70 ou 0,7 pour un focus de 70 % ?
Saisissez 0,7. Le facteur de focus est une fraction comprise entre 0 et 1 : la valeur 70 est refusée au lieu d'être lue comme un pourcentage. Les extrêmes, 0 et 1, sont acceptés.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/biz/team-capacity-sprint \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"headcount":5,"working_days":10,"hours_per_day":8,"focus_factor":0.7}'const res = await fetch("https://api.kit.forhosting.com/biz/team-capacity-sprint", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"headcount": 5,
"working_days": 10,
"hours_per_day": 8,
"focus_factor": 0.7
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/biz/team-capacity-sprint",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"headcount": 5,
"working_days": 10,
"hours_per_day": 8,
"focus_factor": 0.7
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/team-capacity-sprint", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"headcount":5,"working_days":10,"hours_per_day":8,"focus_factor":0.7}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"headcount":5,"working_days":10,"hours_per_day":8,"focus_factor":0.7}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/team-capacity-sprint", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"headcount": 5,
"working_days": 10,
"hours_per_day": 8,
"focus_factor": 0.7
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.team_capacity_sprint",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Les entrées invalides échouent avec invalid_input et ne sont pas facturées.
Contrat d'entrée, forme de la réponse et comportement d'erreur
Un facteur de focus hors de zéro à un échoue aussi — n'envoyez pas soixante-dix pour soixante-dix pour cent. Envoyez en POST un corps JSON avec quatre nombres finis obligatoires : headcount (personnes ou FTE, strictement positif), working_days (nombre positif de jours ouvrés dans le sprint, hors week-ends et jours fériés connus), hours_per_day (heures productives nominales positives par personne et par jour, souvent de six à huit) et focus_factor (disponibilité ou focus comme fraction dans l'intervalle fermé de zéro à un). Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique ; champs manquants, chaînes vides, valeurs non finies et headcount, jours ouvrés ou heures par jour non positifs échouent avec invalid_input en nommant le champ. En cas de succès le corps renvoie les quatre leviers et person_days, gross_hours, capacity_hours, capacity_person_days, overhead_hours, ainsi qu'une chaîne de formule rappelant capacity_hours égale headcount fois working_days fois hours_per_day fois focus_factor. Associez le résultat numérique à vos propres estimations en story points et limites WIP en dehors de cet endpoint ; le calculateur ne renvoie que le budget en heures et personne-jours et n'émet ni tickets Jira, ni commits de tableau, ni graphiques de burndown. Gardez des unités cohérentes sur une série de planification : si vous modelez hours_per_day à six pour des journées d'ingénierie à fort focus, utilisez la même convention lorsque vous comparez ensuite capacity_hours aux heures d'estimation restantes.
Où un calculateur de capacité de sprint d'équipe se justifie
Comme l'implémentation est pure parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant.
Questions techniques
Comment calcule-t-on la capacité de sprint d'équipe ?
capacity_hours = headcount × working_days × hours_per_day × focus_factor. Envoyez un headcount, des jours ouvrés et des heures par jour positifs, plus un facteur de focus entre 0 et 1 ; l'API renvoie aussi les personne-jours, heures brutes et heures de surcharge.
Combien coûte le calculateur de capacité de sprint d'équipe ?
L'outil navigateur est gratuit. Les requêtes API utilisent le solde KIT prépayé à $0.002 par appel réussi ; une entrée invalide n'est pas facturée.