Sprint Backlog: Definición, Ejemplos y Diferencias con el Product Backlog
La mayoría de los equipos que no llegan al sprint commit no tienen un problema de entrega. Tienen un problema de sprint backlog. El trabajo que se metió no estaba refinado, el goal era vago, y no había plan claro de cómo entregarlo. Para el miércoles de la segunda semana, el equipo está rearmando el plan en vivo y soltando items.
Un sprint backlog resuelve esto. Es el conjunto pequeño y bloqueado de trabajo al que el equipo se compromete en un sprint, más el goal que decide qué se queda y el plan de entrega.
Esta guía cubre qué va dentro de un sprint backlog y en qué se diferencia del product backlog. Recorre quién es el dueño real, un ejemplo trabajado y los errores que lo convierten en lista de deseos.
Prueba un sprint backlog
Hay dos historias en el Backlog. Arrástralas por Doing hasta Done a medida que el equipo las toma y las entrega, o agrega una historia tuya.
Arrastra tarjetas entre columnas o haz clic en + para agregar una historia
Toca una tarjeta y luego la cabecera de la columna
Respuesta rápida: qué es un sprint backlog
Un sprint backlog es el conjunto de trabajo que un equipo Scrum se compromete a entregar en un sprint, más un plan de cómo. La Scrum Guide nombra tres partes obligatorias. Un sprint goal que ancla el trabajo, los items sacados del product backlog y un plan de entrega. Se arma en sprint planning, es de los Developers y se bloquea cuando empieza el sprint.
Un tablero de sprint que tu equipo va a usar.
Rock junta un tablero kanban con chat y notas en un mismo space. Precio plano, usuarios ilimitados, sin que el costo crezca por persona.
Sprint backlog vs product backlog
Los dos términos se usan como sinónimos, sobre todo en equipos jóvenes. No son el mismo artefacto. El product backlog es la lista ordenada y completa de todo lo que podría entrar al producto, mantenida limpia y rankeada con backlog grooming continuo. El sprint backlog es el subconjunto pequeño y bloqueado para un sprint.
Si tu equipo solo tiene uno de los dos, lo más probable es que sea el product backlog, y por eso el sprint planning es inestable. El sprint backlog es la parte que protege al equipo de los cambios de alcance durante dos semanas.
| Dimension | Sprint backlog | Product backlog |
|---|---|---|
| Qué es | El conjunto de items que el equipo se compromete a entregar en un sprint, mas el plan de cómo. | La lista ordenada y completa de todo lo que podría entrar al producto, en cualquier momento. |
| Horizonte | Un sprint (de 1 a 4 semanas). | Abierto. Meses o años. |
| De quién es | De los Developers (según la Scrum Guide). El product owner no puede meter items a la fuerza durante el sprint. | Del product owner. Decide qué entra y en qué orden. |
| Estabilidad | Bloqueado en sprint planning. Solo el equipo ajusta el alcance dentro del sprint. | Cambia constantemente. Entran ideas nuevas, salen viejas, las prioridades se reordenan. |
| Partes obligatorias | Un sprint goal, los items seleccionados, y un plan de entrega con tareas. | Items con distintos niveles de detalle. Los de arriba refinados, los de abajo en bruto. |
| Cuándo se crea | En sprint planning, cada sprint. | Una vez, después se refina de forma continua. |
"El Sprint Backlog es un plan por y para los Developers. Es una imagen muy visible y en tiempo real del trabajo que los Developers planean lograr durante el Sprint." - Ken Schwaber y Jeff Sutherland, Scrum Guide 2020
Qué va dentro de un sprint backlog
Un sprint backlog es más estructurado de lo que muchos equipos creen. No es una lista de historias. Es un goal, una selección y un plan, con criterios de aceptación y dueños asignados.
Si falta cualquiera de estas partes, el sprint backlog está incompleto y el sprint en riesgo. La mayoría de los sprints fallidos se rastrean a una de estas brechas.
| Componente | Qué es | Ejemplo |
|---|---|---|
| Sprint goal | Una sola frase que describe lo que el sprint busca lograr. El ancla que decide qué se queda y qué se corta. | "Lanzar el formulario de onboarding para que los account managers dejen de mandar PDFs." |
| Items seleccionados | Las historias de usuario que se sacan del product backlog porque encajan con el goal y la capacidad del equipo. | De 5 a 10 historias, cada una estimada y atada al goal. |
| Criterios de aceptación | Las condiciones por item que definen "hecho." Sin esto, el equipo termina trabajo que el product owner devuelve. | "El formulario valida el correo, captura nombre y empresa, manda confirmación, registra en el CRM." |
| Tareas descompuestas | Los pasos concretos que el equipo va a ejecutar por cada historia. Suelen agregarse en sprint planning. | Crear el schema, escribir validaciones, conectar al CRM, escribir el copy, hacer QA en mobile. |
| Dueño por item | Una persona responsable por cada historia. Dos asignados a una sola historia es una señal de planning flojo. | Alex en el schema del formulario, Priya en la integración con el CRM. |
| Capacidad real | El esfuerzo total estimado entra dentro de la velocity conocida del equipo, con un buffer. | Velocity de 28 puntos; el sprint se compromete a 24. |
Cómo armar un sprint backlog en 5 pasos
El armado pasa en sprint planning, en una sola sesión. El orden importa. Primero el goal, luego la selección, después la estimación, la descomposición y por último el commit.
Saltarse un paso casi nunca funciona. Los equipos que estiman antes de acordar el goal terminan dimensionando items que después cortan. Los que se comprometen sin descomponer en tareas terminan descubriendo el alcance a mitad de sprint.
- Confirma primero el sprint goal Antes de meter ningún item, el product owner pone el goal en una sola frase. "Lanzar el formulario de onboarding para que los account managers dejen de mandar PDFs." Si el equipo no se pone de acuerdo en una frase, el goal no está listo y el resto del planning es adivinar.
- Saca items de un product backlog refinado Solo los items que cumplen la definición de listo entran. Los items refinados tienen criterios de aceptación, una estimación y un dueño claro. Si la parte de arriba del backlog no está refinada, el sprint planning se convierte en backlog grooming disfrazado y el commit se atrasa una hora.
- Estima contra capacidad real Mira los últimos tres sprints. Toma el promedio completado como techo y comprométete con cerca del 80 por ciento, dejando margen para lo que siempre aparece. Un equipo con velocity de 28 puntos se compromete a 22 o 24, no a 30.
- Descompon items en tareas Cada item se rompe en los pasos concretos que el equipo va a ejecutar. "Crear el schema del formulario, escribir validaciones, conectar al CRM, hacer QA en mobile." Las tareas son lo que convierte el sprint backlog de una lista de promesas en un plan que se puede trabajar.
- Cierra el commit y suéltalo Una vez fijado el sprint backlog, el product owner no puede meter items en medio del sprint. El equipo es el dueño. Las ideas nuevas se van al product backlog y esperan al siguiente ciclo. Esta es la regla que protege al sprint del caos de afuera.
De quién es el sprint backlog
El sprint backlog es de los Developers. Esta es una de las frases más citadas de la Scrum Guide y aparece casi tal cual en el examen Professional Scrum Master. El product owner no puede meter items al sprint backlog en medio del sprint, y el scrum master no es dueño del trabajo.
De lo que sí es dueño el product owner es de la prioridad. Decide qué entra al product backlog y en qué orden. Una vez que un item pasa al sprint backlog en planning, el alcance dentro de ese item es decisión del equipo. El scrum master facilita, quita bloqueos y protege al sprint de las interrupciones.
Esta separación existe por algo. Si el product owner pudiera meter items en medio del sprint, cada sprint se vuelve una negociación de lista de deseos. El equipo nunca termina nada y la velocity se cae. La línea dura sobre el ownership es lo que hace que Scrum funcione.
"El enfoque iterativo e incremental de Scrum cambia la certeza de un plan fijo por la flexibilidad de avanzar un Sprint a la vez." - Mike Cohn, Mountain Goat Software
Un ejemplo de sprint backlog
Imagina un equipo de agencia con sprints de dos semanas que va a lanzar el formulario de onboarding de un cliente. La velocity es de 24 puntos. El product owner trae un backlog refinado con 12 items listos. Sprint planning produce este commit.
Sprint goal: Lanzar el formulario de onboarding del cliente para que los account managers dejen de mandar PDFs.
Items seleccionados (5 en total, 22 puntos):
Schema y validación del formulario (5 pts, dueño Alex). Aceptación: captura nombre, empresa, correo, tipo de proyecto. El campo de correo valida. El formulario rechaza campos requeridos vacíos.
Integración con el CRM (8 pts, dueña Priya). Aceptación: el envío crea un contacto nuevo en HubSpot con etiquetas. Los envíos fallidos quedan registrados en Sentry.
Correo de confirmación (3 pts, dueño Alex). Aceptación: el cliente recibe una confirmación con la marca en menos de 30 segundos. Se dispara una notificación interna en Slack al equipo de cuenta.
QA en mobile (3 pts, dueño Sam). Aceptación: el formulario funciona en iOS Safari, Android Chrome y la webview en app. No se rompe el layout a 320px de ancho.
Revisión de copy y lanzamiento (3 pts, dueña Mia). Aceptación: el cliente revisó y aprobó el copy. Se reemplaza el formulario en producción. El link viejo del PDF redirige.
Quedan 2 puntos de buffer sin usar. Es a propósito. El primer ticket de soporte no planeado se los va a comer, y el equipo igual entrega el goal.
Cómo lo hacemos en Rock
Para equipos de agencia que llevan varios sprints de cliente en paralelo, la plantilla de sprint backlog de manual necesita ajustarse. Una agencia de 12 personas con 6 clientes de retainer no corre seis sprints idénticos. Lleva un sprint rotativo por cliente, muchas veces con miembros del equipo que se cruzan.
Usamos un tablero por cliente con tres columnas: Backlog, Doing, Done. El sprint goal queda fijado arriba del space como una nota.
Los items seleccionados para el sprint actual llevan una etiqueta "este sprint" para que se distingan rápido en el tablero. El mismo Developer puede tener 3 items en el space del cliente Acme y 2 items en el space del cliente BetaCo. Todos marcados "este sprint" con la misma fecha de cierre.
El refinamiento async corre en el chat del space. Los criterios de aceptación se afinan en hilos de Topic, no en reuniones de 60 minutos. El product owner confirma el commit del sprint un lunes, el equipo es dueño durante la duración del sprint, y solo se mueven items en medio por swaps negociados.
Este patrón funciona por una sola cosa: el sprint backlog se mantiene bloqueado. Sin ese bloqueo, todo lo demás se cae. El precio plano de Rock significa que el mismo Developer es miembro de los 6 spaces de cliente sin que el costo por usuario crezca. Eso hace viable el patrón de tablero de tareas para agencias pequeñas.
Sprint backlog en agencias LATAM con clientes en EE.UU. y Europa
Para las agencias LATAM que entregan trabajo a clientes en Estados Unidos o Europa, el sprint backlog tiene una capa adicional: el huso horario. El product owner del cliente arranca su día cuando el equipo de la agencia ya lleva tres horas trabajando. Eso cambia cómo se arma el commit y dónde aparecen los riesgos.
El patrón que vemos funcionar mejor combina sprint planning async con un bloque corto en vivo. El equipo prepara la propuesta de sprint backlog antes del lunes en la mañana hora cliente. La llamada de planning queda en 30 minutos en el horario de máximo solapamiento (típicamente 9-10 AM hora del este de EE.UU. para equipos en Colombia, México, Argentina). Lo demás (refinamiento, dudas, swaps) corre en hilos de chat durante el día.
El sprint goal toma protagonismo en este modelo. Con 6 horas de zona horaria entre el equipo y el cliente, el goal evita un riesgo concreto. Que se entreguen 5 historias técnicamente correctas pero que no resuelven el pedido real del negocio. Una frase escrita por el product owner del cliente, leída en voz alta en el planning, vale más que un diagrama de Gantt de tres páginas.
Para agencias pequeñas (3 a 8 desarrolladores) que llevan dos o tres clientes en paralelo, el sprint backlog también funciona como evidencia ante el cliente. Un tablero compartido en Rock con las columnas Backlog, Doing y Done, actualizado en tiempo real, reemplaza el reporte semanal de status y construye confianza en moneda dura.
"El sprint goal es la salsa secreta de un sprint exitoso. Sin él, el equipo tiene una lista de tareas pero ningún foco compartido." - Roman Pichler, Pichler Consulting
Recurso gratis: la plantilla Agile Sprint Planning trae el tablero de Backlog, sprint y review listo para usar.
Sprints multi-cliente, sin contar usuarios.
$89/mes plano para usuarios ilimitados. Cada Developer entra a cada space de cliente sin costos por persona.
Errores comunes que evitar
La mayoría de los sprint backlogs fallan de formas predecibles. El equipo se compromete a demasiado, el goal queda vago, el product owner mete items a mitad de sprint, y los items se arrastran cada ciclo. Son patrones recurrentes, no semanas de mala suerte.
- Sin sprint goal Un sprint backlog sin goal es una checklist. El equipo termina los items pero no puede decir qué logró el sprint. La Scrum Guide trata al sprint goal como parte obligatoria por algo. No te comprometas hasta tenerlo en una sola frase.
- Tratarlo como lista de deseos Los items que no están refinados no tienen lugar en el sprint backlog. Van a necesitar aclaraciones a mitad de sprint, generan retrabajo, y al final se cortan en review o se arrastran. Saca solo items que cumplen la definición de listo del equipo.
- Sobre-comprometerse en capacidad La mayoría de los equipos llena el sprint backlog al 100 por ciento de la velocity del último sprint. La capacidad real es menor por reuniones, soporte y los items no planeados que aparecen cada sprint. Comprométete al 75 a 85 por ciento y deja el buffer.
- El product owner mete items a mitad de sprint Una vez bloqueado el sprint, solo el equipo ajusta el alcance. Si el product owner necesita algo, negocia un swap con el equipo y saca un item equivalente. Si no, el sprint se convierte de nuevo en lista de deseos y la velocity se cae.
- Sin descomposición en tareas Una historia que dice "crear formulario de onboarding" no es un item de sprint backlog. Es un placeholder. El equipo no sabe quién la toma primero ni cómo se ve "hecho" a nivel de tarea. Se descompone en planning, no a mitad del sprint.
- Arrastrar items cada sprint Si dos o tres items se arrastran cada sprint, el equipo está sobre-comprometiéndose y el sprint backlog dejó de significar algo. Recorta el commit hasta que el equipo lo termine de verdad. La retrospectiva debería sacar esto a la luz; si no, hay que hacer mejores preguntas.
Preguntas frecuentes
¿Qué es un sprint backlog?
Un sprint backlog es el conjunto de trabajo que un equipo Scrum se compromete a entregar en un solo sprint, junto con el plan de cómo lo va a entregar. La Scrum Guide nombra tres partes obligatorias: un sprint goal, los items seleccionados del product backlog y un plan de entrega. Se arma en sprint planning y queda bloqueado una vez empieza el sprint.
¿De quién es el sprint backlog?
De los Developers. La Scrum Guide es explícita: "El Sprint Backlog es un plan por y para los Developers." El product owner puede negociar el alcance con el equipo, pero no puede meter items al sprint backlog de forma unilateral una vez empezado el sprint.
¿Quién ejecuta el trabajo del sprint backlog?
Solo los Developers (los miembros del equipo que construyen el incremento) ejecutan el trabajo. El product owner define la prioridad, el scrum master facilita el proceso, pero el trabajo en sí lo hacen los Developers. Esta es una de las preguntas más comunes del examen Professional Scrum Master.
¿Cuál es la diferencia entre sprint backlog y product backlog?
El product backlog es la lista ordenada y completa de cada item que podría entrar al producto. Es del product owner y cambia constantemente. El sprint backlog es un subconjunto pequeño, sacado en sprint planning, dueño los Developers, y bloqueado por el resto del sprint.
¿El sprint backlog puede cambiar durante el sprint?
Sí, pero solo los Developers lo cambian. A medida que el equipo aprende durante el sprint, puede agregar tareas, dividir items o sacar trabajo que ya no sirve al sprint goal. Lo que no puede hacer es aceptar items nuevos que mete el product owner. Si hace falta un swap, el equipo y el product owner negocian, y se saca un item equivalente.
¿Existe una plantilla de sprint backlog?
Un sprint backlog tiene más que ver con la estructura que con un formato fijo. La forma mínima es un tablero con tres columnas (Backlog, Doing, Done), donde cada item tiene título, estimación, dueño y criterios de aceptación. La plantilla Agile Sprint Planning de Rock viene con ese mismo layout. Notion, Jira y la mayoría de las herramientas de tareas tienen tableros parecidos integrados.
¿Cuántos items debería tener un sprint backlog?
Los que entren en la velocity del equipo para un sprint, con un buffer pequeño. Para la mayoría de los equipos de 5 personas con sprints de dos semanas, son entre 5 y 10 historias de usuario. Menos de 5 y el sprint goal probablemente está demasiado acotado. Más de 10 y los items son demasiado pequeños o el equipo se está sobre-comprometiendo.
Un sprint backlog claro es lo que separa a un equipo que entrega de uno que improvisa. Rock combina chat, tareas y notas en un solo workspace. Precio plano, usuarios ilimitados. Empieza gratis.
