Calculateur de burndown

Le graphique de burndown d’un sprint est la droite qui montre comment les story points restants doivent descendre du total engagé jusqu’à zéro le dernier jour de l’itération. Ce calculateur de graphique burndown prend trois nombres — total de story points, jours du sprint et jours écoulés — et renvoie le travail restant idéal au jour écoulé, plus le travail restant idéal de chaque jour du sprint. L’identité est remaining de d égal au total de story points fois un moins d sur les jours du sprint. Lorsque les jours du sprint valent zéro, la pente est indéfinie, si bien que la tâche échoue avec invalid_input et n’est pas facturée.

Ce qu’est la ligne idéale de burndown et comment le reste se forme

La ligne idéale de burndown est une descente droite depuis le total de story points engagés au jour zéro jusqu’à zéro de travail restant le dernier jour du sprint. Cette géométrie est la définition que tout manuel Scrum et tout outil de backlog tracent en premier : le travail restant au jour d égale le total de story points fois un moins d divisé par les jours du sprint. La pente de cette droite est le burn quotidien — le total de story points divisé par les jours du sprint —, c’est-à-dire combien de points l’équipe devrait terminer chaque jour si le progrès était parfaitement uniforme. Cet endpoint n’ingère pas un export Jira, ne compare pas le travail restant réel à la consigne et ne prévoit pas si l’équipe finira.

Contrat d’entrée, forme de la réponse et erreurs

Envoyez par POST un corps JSON avec trois nombres finis obligatoires. total_story_points est le total engagé au lancement ; les alias story_points, points et total pointent vers le même champ pour qu’une colonne du tableau conserve son nom. sprint_days est la durée de l’itération en jours ; les alias days, duration et sprint sont acceptés. elapsed_days est le nombre de jours déjà passés, zéro à la planification ; les alias elapsed et elapsed_day sont acceptés. Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique. Les champs manquants, les chaînes vides et les valeurs non finies échouent avec invalid_input en nommant le champ. Si sprint_days dépasse trois cent soixante-six, la requête échoue pour que la série remaining_per_day reste bornée. Si total_story_points ou elapsed_days est négatif, la requête échoue. Ces échecs ne sont pas facturés. Si la validation passe, le corps répète les trois entrées, puis rapporte daily_burn, remaining_ideal au jour écoulé (borné à zéro après le dernier jour du sprint), completed_ideal comme complément, progress_percent comme écoulé sur sprint mis à l’échelle de cent et plafonné à cent, days_remaining, remaining_per_day comme liste de paires day et remaining du jour zéro jusqu’au dernier jour du sprint, et une chaîne formula qui reformule l’identité. Exemple : cent story points, dix jours de sprint et quatre jours écoulés donnent daily_burn dix, remaining_ideal soixante, completed_ideal quarante, progress_percent quarante et onze lignes remaining_per_day de cent jusqu’à zéro. Associez le JSON à votre propre série restante réelle si vous avez besoin de la ligne rouge à côté de la consigne ; cet endpoint calcule uniquement la ligne idéale.

Où un calculateur de graphique burndown apporte de la valeur

Les scrum masters utilisent un calculateur de graphique burndown lorsque le tableau affiche déjà les points engagés et les jours calendaires et qu’ils ont besoin de la même consigne que leur diapositive de stand-up imprimera, sans ouvrir un outil de projet pour une identité à trois nombres. C’est une recherche et un travail différents du calcul de la vélocité, du cycle time ou de la valeur acquise : ces métriques exigent un historique achevé ou des pondérations en monnaie, tandis qu’un burndown idéal n’utilise que le total engagé, la durée du sprint et le nombre de jours écoulés. Une validation en échec ne consomme pas de solde. Les responsables de programme recalculent remaining_ideal par équipe afin qu’une revue de portefeuille compare jusqu’où chaque sprint aurait dû brûler au même jour écoulé, avec une seule règle d’arrondi partagée. Les partenaires financiers qui dimensionnent la livraison selon le burn de story points extraient total_story_points, sprint_days et elapsed_days de la feuille de planification et figent remaining_ideal dans un modèle qui ne doit pas appeler une API de suivi propriétaire. Comme l’implémentation est parse pure 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. Gardez sprint_days strictement positif, le total engagé et les jours écoulés non négatifs, figez la série remaining_per_day dans les tests, et vous obtenez un burndown idéal reproductible pour tableaux de bord, plugins LMS et workers de bord sans dresser un moteur de suivi de projet à vous.