Calculadora de burndown

Quando os dias do sprint são zero, a inclinação fica indefinida, então a tarefa falha com invalid_input e não é cobrada.

O que é a linha ideal de burndown e como o trabalho restante é formado

Este endpoint não ingere uma exportação do Jira, não compara o trabalho restante real com a diretriz e não prevê se a equipe vai terminar.

Contrato de entrada, forma da resposta e erros

Envie por POST um corpo JSON com três números finitos obrigatórios. total_story_points é o total comprometido na largada; os aliases story_points, points e total apontam para o mesmo campo para que uma coluna do quadro conserve o nome. sprint_days é a duração da iteração em dias; os aliases days, duration e sprint são aceitos. elapsed_days é quantos dias já passaram, zero no planejamento; os aliases elapsed e elapsed_day são aceitos. Cada campo pode chegar como número JSON ou string numérica. Campos ausentes, strings vazias e valores não finitos falham com invalid_input nomeando o campo. Se sprint_days for maior que trezentos e sessenta e seis, o pedido falha para a série remaining_per_day permanecer limitada. Se total_story_points ou elapsed_days for negativo, o pedido falha. Essas falhas não são cobradas. Se a validação passar, o corpo ecoa as três entradas, informa daily_burn, remaining_ideal no dia decorrido (limitado a zero após o último dia do sprint), completed_ideal como complemento, progress_percent como decorrido sobre sprint escalado a cem e limitado a cem, days_remaining, remaining_per_day como lista de pares day e remaining do dia zero até o último dia do sprint, e uma string formula que reitera a identidade. Exemplo: cem pontos de história, dez dias de sprint e quatro dias decorridos geram daily_burn dez, remaining_ideal sessenta, completed_ideal quarenta, progress_percent quarenta e onze linhas de remaining_per_day de cem até zero. Combine o JSON com a sua própria série restante real se precisar da linha vermelha ao lado da diretriz; este endpoint calcula só a linha ideal.

Onde uma calculadora de gráfico burndown gera valor

Scrum masters usam uma calculadora de gráfico burndown quando o quadro já mostra os pontos comprometidos e os dias de calendário e precisam da mesma diretriz que o slide da reunião diária vai imprimir, sem abrir uma ferramenta de projeto por uma identidade de três números. Esta é uma busca e um trabalho diferentes de calcular velocidade, cycle time ou valor agregado: essas métricas precisam de histórico concluído ou pesos em dinheiro, enquanto um burndown ideal usa só o total comprometido, a duração do sprint e quantos dias se passaram. Validação falha não consome saldo. Gestores de programa recalculam remaining_ideal por esquadrão para que uma revisão de portfólio compare até onde cada sprint deveria ter queimado no mesmo dia decorrido, com uma só regra de arredondamento compartilhada. Sócios financeiros que dimensionam a entrega contra o burn de pontos de história tiram total_story_points, sprint_days e elapsed_days da planilha de planejamento e fixam remaining_ideal num modelo que não deve chamar uma API de rastreador proprietária. Como a implementação é parse puro de nível A, cada chamada bem-sucedida custa o preço base publicado US$ 0,002 sem tokens de modelo nem rede de saída. Mantenha sprint_days estritamente positivo, o total comprometido e os dias decorridos não negativos, fixe a série remaining_per_day nos testes e você obtém um burndown ideal reproduzível para painéis, plugins LMS e workers de borda sem montar um motor de rastreamento de projetos próprio.