Cómo hacer sprints en un equipo pequeño de cinco: tres reuniones, dos números y sin story points

La respuesta corta: tres reuniones y dos números

Un sprint es un periodo fijo en el que el equipo se compromete con un conjunto de trabajo elegido. Para cinco personas, lo útil es el compromiso y la fecha de cierre fija. Ambos obligan a hablar de lo que importa esta quincena y hacen visibles los retrasos pronto.

Lo que un equipo de cinco no necesita es un proceso pensado para coordinar varios equipos, un Scrum Master dedicado ni un sistema de previsión basado en estimaciones. La propia Guía de Scrum describe equipos de normalmente diez personas o menos y permite hasta ocho horas de planificación para un sprint de un mes. Con cinco personas y dos semanas, ese presupuesto supera con mucho lo que hace falta.

Así que el método conserva:

• Una duración, fija. Dos semanas salvo que tengas un motivo. Cambiar la duración en cada sprint destruye cualquier comparación.
• Un objetivo por sprint. Una frase, no una lista. «Los clientes pueden pagar con factura» es un objetivo; «trabajar en facturación» no lo es.
• Tres reuniones. Planificación, control a mitad y demo. Unos 90 minutos de reuniones en diez días laborables.
• Dos números. Rendimiento (tareas terminadas) y arrastre (tareas que pasan al siguiente sprint).

Por qué Scrum completo es demasiado para cinco personas

Los eventos de Scrum existen por buenas razones, y los tiempos de la Guía son máximos, no objetivos. El problema para un equipo pequeño es el coste fijo. Un daily de 15 minutos cuesta a un equipo de cinco 75 minutos-persona al día, unas seis horas-persona por sprint de dos semanas antes de que nadie se alargue. Una retrospectiva en cada sprint, una sesión de refinamiento y una revisión suman más.

Con cinco personas, casi todo lo que esas reuniones sacan a la luz ya es visible. Todos ven el tablero, todos están en el mismo chat, y quien está bloqueado por una decisión de API suele decirlo en menos de una hora. Las reuniones que siguen compensando son las que fuerzan una decisión que nadie tomaría de otro modo: con qué nos comprometemos, si seguimos en camino y si lo que construimos vale la pena.

En nuestro trabajo, las reuniones que quitamos fueron las que repetían lo que el tablero ya mostraba: la ronda diaria de novedades y la discusión de estimaciones. Las que mantuvimos son aquellas en las que el equipo tiene que elegir algo en conjunto.

El sprint mínimo para un equipo de cinco

Esto es lo que conservamos de cada evento de Scrum y lo que sustituye al resto.

El total de reuniones queda entre unos 90 minutos y dos horas y media por sprint, frente a las ocho horas o más de la versión al pie de la letra.

Cómo hacer un sprint de dos semanas, paso a paso

Los pasos suponen dos semanas, diez días laborables y un backlog ya ordenado a grandes rasgos. Si tu backlog es un caos, dedica una hora a ordenar los 20 primeros elementos antes de la primera planificación; será la mejor hora que inviertas.

Día 1: planificación (45 minutos)

1. Mira los números del sprint anterior (5 minutos). Cuántas tareas se terminaron y cuántas se arrastraron. Esa es tu guía de capacidad.
2. Escribe el objetivo (10 minutos). Una frase que diga qué será cierto al final. Lo propone quien lleva el producto; el equipo lo discute.
3. Elige el trabajo que sirve al objetivo (20 minutos). Desde arriba del backlog, toma tareas hasta llegar más o menos al rendimiento del sprint anterior. Lo que no sirva al objetivo necesita un motivo para estar.
4. Asigna un responsable a cada tarea (5 minutos). Una persona por tarea. Una tarea compartida es una tarea sin dueño.
5. Nombra el riesgo (5 minutos). Lo que con más probabilidad hundiría el objetivo. Escríbelo debajo del objetivo.

La plantilla de planificación de sprint tiene esta agenda, una tabla de capacidad y un sitio para el objetivo, y sirve lo llames sprint o ciclo.

Cada día: actualización asíncrona en lugar de daily

Cada persona escribe dos o tres líneas en un hilo del chat del equipo a media mañana: qué terminó, en qué está y qué le bloquea. Se tarda dos minutos en escribirlo y dos en leerlo. Los bloqueos se resuelven con una respuesta en el hilo o una llamada rápida entre las dos personas implicadas, no con una reunión de cinco.

Día 6: el control a mitad de sprint (15 minutos)

Es la reunión que Scrum no tiene y la que más necesita un equipo pequeño. A mitad del sprint, mira el tablero y haz una sola pregunta: ¿vamos a cumplir el objetivo? Si la respuesta es no, decide ahora qué recortar, no el día diez. Sacar dos tareas el día seis es un plan. Descubrir el día diez que cuatro tareas no se hicieron es una sorpresa.

Día 10: demo y cierre (30 minutos)

Enseña lo que se entregó, en el producto, no en diapositivas. Después cierra el sprint: lo terminado queda hecho, y cada tarea sin terminar pasa al siguiente sprint o vuelve al backlog. Decide cuál a propósito. Usa los últimos cinco minutos para una pregunta, «¿qué deberíamos hacer distinto la próxima vez?», y apunta como mucho un cambio.

Qué medir: rendimiento y arrastre

Dos números bastan para un equipo de cinco.

El rendimiento es el número de tareas terminadas en el sprint. Contar tareas es más tosco que los puntos, pero cuesta manipularlo y no exige reunión de estimación. Tras tres o cuatro sprints se estabiliza en un rango, por ejemplo de 18 a 24 tareas para un equipo de cinco, y ese rango es tu capacidad para la siguiente planificación. Funciona mejor si las tareas tienen un tamaño parecido, así que divide todo lo que lleve más de tres o cuatro días.

El arrastre es el número de tareas que estaban en el sprint y no se terminaron. Un poco es normal. Mucho, o la misma tarea arrastrada tres sprints seguidos, es la señal que importa: el equipo planifica de más, la tarea es demasiado grande o está bloqueada por algo que nadie ha nombrado. En cada planificación miramos el arrastre antes que el rendimiento.

Si quieres un tercer número, apunta cuántas veces se cumplió el objetivo del sprint. Un equipo que lo cumple cuatro de cada cinco sprints, aunque arrastre alguna tarea, funciona bien.

Qué omitir: story points, velocidad y casi todos los gráficos

Los story points sirven para prever cuánto trabajo cabe en un periodo. Con cinco personas, su previsión rara vez es mejor que contar tareas, y las reuniones de estimación cuestan tiempo real. Tienen sentido cuando debes dar fechas de entrega a un cliente a partir de datos históricos, o cuando el tamaño de las tareas varía muchísimo y no puedes dividirlas. Si no, omítelos.

Los gráficos de velocidad dependen de los puntos, así que también sobran. Los diagramas de flujo acumulado y similares son útiles con veinte personas; con cinco, el propio tablero muestra dónde se atasca el trabajo.

Un burndown de tareas abiertas es el único gráfico que merece la pena, porque responde de un vistazo a la pregunta de mitad de sprint.

Linear, Jira y Atrix para sprints en equipos pequeños

Los tres llevan bien los sprints de un equipo pequeño. Se diferencian en lo que deciden por ti. Los datos proceden de la documentación y las páginas de precios de cada proveedor, a octubre de 2026.

Linear es lo más parecido al método de arriba. Su documentación de ciclos describe el paso automático del trabajo pendiente, un cooldown opcional entre ciclos y una capacidad estimada con los tres últimos ciclos completados. Para un equipo de cinco, la página de precios de Linear muestra un plan gratuito que cubre a equipos pequeños hasta que superan las 250 issues.

Jira te da el mayor control. Al completar un sprint, la documentación de Jira ofrece tres destinos para el trabajo sin terminar: el backlog, un sprint futuro ya creado o uno nuevo. Es la opción correcta si quieres que una persona decida el arrastre cada vez, y el plan gratuito de Jira cubre hasta 10 usuarios.

Atrix es la herramienta que construimos, así que primero sus límites. Tiene ciclos de una a cuatro semanas por producto, cada uno con un objetivo y un burndown que cuenta tareas abiertas, y al completar un ciclo el trabajo pendiente pasa al siguiente o vuelve al backlog. Las etiquetas de colores y los hitos están al lado. A propósito no tiene story points, ni informes de velocidad, ni ajuste de cooldown; si tu proceso depende de alguno, usa Linear o Jira. Atrix tiene sentido cuando el equipo también quiere documentos, chat, un CRM y contratación en el mismo espacio. La página de gestión de proyectos explica lo que hace, y nuestra comparación con Linear dice con franqueza dónde Linear es mejor.

Errores habituales en los sprints de equipos pequeños

• Sin objetivo, solo una lista. Sin una frase de intención, todas las tareas parecen igual de importantes y no se recorta nada a mitad de sprint.
• Planificar según la esperanza, no según el historial. Si terminaste 20 tareas el último sprint, planificar 35 no es ambición: es arrastre programado por adelantado.
• Saltarse el control a mitad. La sorpresa del final casi siempre existía ya el día seis.
• Tareas demasiado grandes para terminarlas. Una tarea que ocupa todo el sprint no te dice nada hasta el último día. Divídela.
• Cambiar la duración. Un sprint de una semana después de uno de tres hace que ningún número signifique nada.

Para la diferencia entre las palabras sprint y ciclo, y por qué algunas herramientas pasan el trabajo sin preguntar, lee ciclos frente a sprints.

Preguntas frecuentes

¿Cuánto debe durar un sprint en un equipo pequeño?

Dos semanas encajan en la mayoría de los equipos de producto pequeños: tiempo suficiente para terminar algo que enseñar y lo bastante corto como para que un mal plan cueste poco. Una semana sirve a equipos que publican a diario; tres o cuatro, al trabajo con mucha investigación. La Guía de Scrum limita los sprints a un mes.

¿Necesita un equipo pequeño un daily?

Normalmente no como reunión. Una actualización escrita en un hilo del chat da la misma información en pocos minutos y no interrumpe la concentración de nadie. Mantén un daily en directo solo si los bloqueos siguen sin decirse por escrito.

¿Debe un equipo de cinco usar story points?

Normalmente no. Contar tareas terminadas da un rango de capacidad suficiente para planificar, sin reunión de estimación. Los puntos ayudan cuando debes prever fechas de entrega para clientes o cuando el tamaño de las tareas varía demasiado para dividirlas.

¿Qué hacer con el trabajo sin terminar al final del sprint?

Decide una regla y aplícala. O todo lo pendiente pasa al siguiente sprint, como hace Linear automáticamente, o cada elemento se revisa y va al siguiente sprint o vuelve al backlog, como te pide elegir Jira. Vigila cualquier tarea que se arrastre dos veces.

¿Sirve Scrum para un equipo de cinco?

El tamaño de equipo de la Guía de Scrum, diez personas o menos, incluye a cinco, así que en principio sí. En la práctica, casi todos los equipos de cinco conservan el periodo fijo, el objetivo y la revisión de Scrum, y sustituyen el daily y la retrospectiva completa por versiones más ligeras.

Siguiente paso

Copia la plantilla de planificación de sprint para tu próxima planificación y lee la entrada de sprint en el glosario para tener los términos de Scrum en un solo sitio.