Burndown de sprint
Con 80 puntos comprometidos, 32 completados y 6 días por delante, el equipo necesita 8 puntos de historia por día para cerrar los 48 pendientes. Compare ese ritmo con lo que el equipo entrega de verdad. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Total de puntos de historia
- 80
- Días transcurridos
- 4
- Días restantes
- 6
- Puntos completados
- 32
- Puntos restantes
- 48
- Velocidad diaria requerida
- 8
Esta calculadora de burndown convierte el estado actual de una iteración en un dato práctico para planificar: los puntos de historia que deben completarse por cada día restante para llegar a tiempo. Introduzca el compromiso original del sprint, los días transcurridos, los días disponibles y los puntos terminados. El resultado muestra tanto el trabajo pendiente como la velocidad diaria necesaria, para que usted pueda contrastar el ritmo exigido con la capacidad realista del equipo antes de que finalice el sprint.
Convierta una instantánea del burndown en un objetivo diario claro
Un gráfico de burndown muestra la dirección, pero no siempre responde a la pregunta que surge en la revisión diaria: ¿a qué ritmo debe avanzar ahora el trabajo pendiente? Esta calculadora parte del total de puntos de historia del sprint y resta los puntos ya completados. Después divide ese trabajo sin terminar entre los días que todavía están disponibles.
La velocidad diaria necesaria resultante es un objetivo orientado al futuro, expresado en puntos de historia por día restante. Si queda mucho trabajo y apenas unos días, el objetivo elevado aparece de inmediato, sin depender de una interpretación visual de la tendencia. Incluya todos los días transcurridos, incluso aquellos en los que no se terminó ningún punto, para que la instantánea describa el calendario con honestidad.
El valor transcurrido se devuelve como contexto; el cálculo del plazo usa los días restantes porque representan las oportunidades que aún tiene el equipo. Utilice el resultado como señal de planificación, no como cuota de productividad individual.
Interprete la velocidad necesaria dentro del contexto de entrega
La velocidad diaria necesaria expresa el ritmo aritmético requerido para consumir la estimación pendiente antes de la fecha límite. Compárela con los puntos que el equipo suele completar por día, el rendimiento reciente, el trabajo en curso y los impedimentos conocidos. Si el objetivo está cómodamente por debajo de un ritmo sostenible, el sprint sigue siendo viable desde el punto de vista matemático.
Si está muy por encima, la respuesta útil no consiste en presionar a las personas para inflar la producción. Conviene revisar si puede desbloquearse una tarea, si las historias pueden dividirse sin perder resultados valiosos o si debe renegociarse el alcance con la persona responsable del producto. Un resultado de cero significa que todos los puntos comprometidos ya están completados y no se necesita velocidad adicional.
Los resultados fraccionarios son normales: representan un promedio para los días restantes, no la obligación de completar una parte de una historia cada día. Los puntos son estimaciones relativas al equipo; compare la cifra únicamente con datos del mismo equipo y del mismo método de estimación.
Mantenga entradas coherentes y trate correctamente el límite del plazo
Use unidades coherentes en todos los campos. El trabajo total y el completado deben emplear puntos de historia de la misma línea base del sprint; el tiempo transcurrido y el restante deben compartir la misma definición de día, normalmente días laborables planificados y no días naturales. Actualice los puntos completados según la definición de terminado acordada por el equipo.
Contar trabajo parcial reduce de forma aparente la estimación pendiente sin producir un incremento entregable. La calculadora rechaza puntos completados superiores al total original porque esa combinación no puede representar el trabajo restante respecto al compromiso indicado. También rechaza valores negativos, números no finitos y días fraccionarios.
En particular, cero días restantes produce un error: cuando no queda ningún día, una división no puede ofrecer un ritmo diario útil. En ese límite, revise directamente el resultado del sprint en lugar de interpretar un valor infinito o indefinido.
Qué puede hacer con ella
Prepare la reunión diaria
Calcule el ritmo necesario desde hoy y lleve a la conversación del equipo una señal concreta sobre el riesgo de entrega.
Evalúe un ajuste de alcance
Vuelva a calcular tras retirar o dividir trabajo para comprobar si el compromiso revisado encaja con un ritmo sostenible.
Preguntas frecuentes
¿Qué significa la velocidad diaria necesaria?
Es el resultado de dividir los puntos de historia pendientes entre los días restantes: el promedio de puntos que deben llegar a terminado cada día para completar a tiempo el compromiso indicado.
¿Por qué se solicitan los días transcurridos si la fórmula usa los restantes?
Los días transcurridos conservan en el resultado la instantánea completa del sprint y permiten confirmar que el calendario introducido es comprensible. El ritmo futuro depende de las oportunidades aún disponibles.
¿Qué ocurre cuando no queda ningún día?
El cálculo devuelve un error de entrada no válida, porque repartir trabajo pendiente entre cero días no permite obtener una velocidad diaria con sentido.
¿Pueden los puntos completados superar el total original?
No. La calculadora rechaza esa entrada porque mide el trabajo pendiente respecto al compromiso total indicado. Si se añadió alcance formalmente, utilice el nuevo total.
¿Qué hago si la velocidad diaria necesaria es demasiado alta?
No presione a las personas para inflar la producción. Revise si algún elemento bloqueado puede desbloquearse, si conviene dividir historias conservando su valor o si debe renegociar el alcance con el responsable de producto.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/biz/burndown-remaining-estimate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"total_story_points":80,"days_elapsed":4,"days_remaining":6,"points_completed":32}'const res = await fetch("https://api.kit.forhosting.com/biz/burndown-remaining-estimate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"total_story_points": 80,
"days_elapsed": 4,
"days_remaining": 6,
"points_completed": 32
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/biz/burndown-remaining-estimate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"total_story_points": 80,
"days_elapsed": 4,
"days_remaining": 6,
"points_completed": 32
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/burndown-remaining-estimate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"total_story_points":80,"days_elapsed":4,"days_remaining":6,"points_completed":32}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"total_story_points":80,"days_elapsed":4,"days_remaining":6,"points_completed":32}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/burndown-remaining-estimate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"total_story_points": 80,
"days_elapsed": 4,
"days_remaining": 6,
"points_completed": 32
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.burndown_remaining_estimate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Mantenga entradas coherentes y trate correctamente el límite del plazo
Para automatizar, la API devuelve entradas normalizadas, puntos pendientes y velocidad diaria en un objeto JSON estable. Cada llamada cuesta $0.002; el mismo cálculo determinista funciona en el navegador sin acceso a la red.
Casos de integración
Añada una señal al informe del sprint
Use el resultado determinista de la API en un panel, un informe de estado o una comprobación automática del riesgo de entrega.
Preguntas técnicas
¿Cuánto cuesta una solicitud a la API?
Cada solicitud a la API cuesta $0.002. El cálculo del navegador utiliza la misma lógica determinista y puede ejecutarse localmente.