Calculadora de gráfico burndown

Cuando los días del sprint son cero, la pendiente queda indefinida, de modo que la tarea falla con invalid_input y no se factura.

Qué es la línea ideal de burndown y cómo se forma el trabajo restante

Este endpoint no ingiere una exportación de Jira, no compara el trabajo restante real con la guía y no pronostica si el equipo terminará.

Contrato de entrada, forma de la respuesta y errores

Esos fallos no se facturan. Envíe por POST un cuerpo JSON con tres números finitos obligatorios. total_story_points es el total comprometido al arranque; los alias story_points, points y total apuntan al mismo campo para que una columna del tablero conserve su nombre. sprint_days es la duración de la iteración en días; se aceptan los alias days, duration y sprint. elapsed_days es cuántos días han pasado ya, cero en la planificación; se aceptan los alias elapsed y elapsed_day. Cada campo puede llegar como número JSON o como cadena numérica. Los campos ausentes, las cadenas vacías y los valores no finitos fallan con invalid_input nombrando el campo. Si sprint_days es mayor que trescientos sesenta y seis, la petición falla para que la serie remaining_per_day permanezca acotada. Si total_story_points o elapsed_days es negativo, la petición falla. Si la validación pasa, el cuerpo repite las tres entradas, informa daily_burn, remaining_ideal en el día transcurrido (acotado a cero tras el último día del sprint), completed_ideal como complemento, progress_percent como transcurrido entre sprint escalado a cien y limitado a cien, days_remaining, remaining_per_day como lista de pares day y remaining desde el día cero hasta el último día del sprint, y una cadena formula que reitera la identidad. Ejemplo: cien puntos de historia, diez días de sprint y cuatro días transcurridos dan daily_burn diez, remaining_ideal sesenta, completed_ideal cuarenta, progress_percent cuarenta y once filas de remaining_per_day de cien hasta cero. Combine el JSON con su propia serie restante real si necesita la línea roja junto a la guía; este endpoint calcula solo la línea ideal.

Dónde aporta valor una calculadora de gráfico burndown

Los scrum masters usan una calculadora de gráfico burndown cuando el tablero ya muestra los puntos comprometidos y los días de calendario y necesitan la misma guía que imprimirá su diapositiva de la reunión diaria, sin abrir una herramienta de proyecto por una identidad de tres números. Es una búsqueda y un trabajo distintos de calcular la velocidad, el cycle time o el valor ganado: esas métricas necesitan historial completado o pesos en dinero, mientras que un burndown ideal usa solo el total comprometido, la duración del sprint y cuántos días han transcurrido. La validación fallida no consume saldo. Los gestores de programa recalculan remaining_ideal por escuadrón para que una revisión de cartera compare hasta dónde debería haber quemado cada sprint el mismo día transcurrido, con una sola regla de redondeo compartida. Los socios financieros que dotan la entrega según el burn de puntos de historia toman total_story_points, sprint_days y elapsed_days de la hoja de planificación y fijan remaining_ideal en un modelo que no debe llamar a una API de seguimiento propietaria. Como la implementación es parse pura de nivel A, cada llamada correcta cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente. Mantenga sprint_days estrictamente positivo, el total comprometido y los días transcurridos no negativos, fije la serie remaining_per_day en las pruebas y obtendrá un burndown ideal reproducible para tableros, plugins LMS y workers de borde sin montar un motor de seguimiento de proyectos propio.