Trabajamos durante años con sprints de 2 semanas porque era lo que decía Scrum. Hace 14 meses cambiamos a 1 semana en uno de nuestros proyectos como experimento. Los resultados fueron tan buenos que no volvimos. Hoy todos los proyectos de Sirius corren en sprints semanales. Esta es la nota con los datos.
💰 ¿Cuánto cuesta un proyecto en sprints semanales? Ver la guía completa de pricing en Costa Rica — cobramos por entregable, no por hora, así sabes el total antes de firmar.
El problema de las 2 semanas
El sprint de 2 semanas tiene un problema que nadie reconoce públicamente: hay 10 días donde el equipo puede ir en dirección equivocada antes de que el cliente lo vea. En la práctica esto se traduce en tres síntomas:
- Reuniones ad-hoc no planificadas. En el día 5 o 6 alguien dice "esto no está saliendo como pensábamos" y se monta una sync improvisada. La planificación de sprint que era 1 hora se convierte en 3 horas distribuidas en el sprint.
- Demos teóricas en vez de funcionales. Cuando el sprint llega y la pieza no terminó, la demo se reemplaza por una presentación de slides "explicando lo que estamos construyendo". Los slides no son producto.
- El cliente pierde tracción. Dos semanas es suficiente tiempo para que el cliente se enfríe del proyecto: olvida detalles, prioriza otras cosas, y cuando llega la demo no recuerda qué iba a decidir.
Lo medimos en nuestros propios proyectos. Entre el sprint 1 y el sprint 4 con ciclo de 2 semanas, el tiempo perdido por re-trabajo era 18% del esfuerzo del sprint. Casi un quinto del tiempo se reciclaba.
Lo que cambia con 1 semana
1. La demo del viernes es ley
Cuando hay 5 días en vez de 10, no hay margen para "casi listo". O se entrega algo demostrable o no se entrega. Esto suena duro pero es liberador — el equipo deja de prometer features grandes en 5 días y empieza a partirlas en piezas que sí caben. La división es el ejercicio donde el producto mejora.
En los últimos 12 proyectos con ciclo semanal, el porcentaje de sprints donde sí hubo demo funcional subió de 67% (con ciclo de 2 semanas) a 91%. Cuatro veces más demos reales.
2. Las decisiones del cliente llegan más rápido
El cliente decide cosas cada viernes en la demo y cada lunes en la planificación. Eso son 2 decisiones por semana vs 1 cada dos semanas (la planificación) o 1 por sprint (la demo). El doble de oportunidades de corregir rumbo, con menos drama por decisión.
3. Reuniones ad-hoc se acaban
Como el ciclo es corto, la persona que iba a montar una sync improvisada el día 7 dice "ya casi llega la demo, lo comentamos ahí". El número de reuniones espontáneas en nuestros últimos 6 proyectos bajó de 2.1/semana (con ciclo de 2 semanas) a 0.3/semana. El 86% menos.
La cifra dura: 12 proyectos comparados
Tomamos 6 proyectos antes del cambio (ciclo de 2 semanas) y 6 después (ciclo de 1 semana), todos con equipo similar y alcance comparable:
| Métrica | 2 semanas | 1 semana | Cambio |
|---|---|---|---|
| % sprints con demo funcional | 67% | 91% | +24 pp |
| Horas/semana en reuniones | 5.8 | 2.4 | −59% |
| Retrabajo (% esfuerzo) | 18% | 13% | −28% |
| Reuniones ad-hoc por semana | 2.1 | 0.3 | −86% |
| NPS del cliente al cierre | 53 | 73 | +37% |
| Días totales del proyecto (proyecto medio) | 84 | 71 | −15% |
La línea más interesante: los proyectos cierran un 15% más rápido con sprints semanales, no más despacio. La intuición común es "más demos = más tiempo perdido en demos", pero pasa al revés — menos retrabajo compensa por mucho el costo del overhead.
Cómo lo corremos en Sirius
La estructura semanal nuestra:
- Lunes 9–9:30 am: planning. Repasamos qué cerró la semana pasada, qué falta, qué entra en esta semana. Máximo 5 tareas grandes por equipo de 2 personas.
- Lunes–jueves: trabajo. Stand-up async diario en Linear/Slack (no hay daily presencial — los textos quedan registrados y se leen rápido).
- Viernes 2–2:30 pm: demo con cliente. Cada pieza terminada se muestra funcionando (no slides). El cliente prueba en vivo si aplica.
- Viernes 2:30–3 pm: retro corta. ¿Qué funcionó, qué no, qué cambiamos para la próxima?
Total: 1.5 horas de reuniones por semana, incluyendo al cliente. El resto del tiempo el equipo está construyendo.
Cuándo NO funciona
Hay 2 casos donde el ciclo semanal no aplica:
- Investigación pura. Cuando estamos haciendo discovery (semana 1–2 de un proyecto nuevo) no se demuestra "feature funcional" — se demuestra "entendimiento". Allí el ciclo se vuelve diario (mucho contexto a confirmar).
- Cliente que no puede estar 30 min/semana. Si el cliente no tiene disponibilidad de 30 minutos los viernes, no hay decisión, no hay demo, no hay sprint. Mejor hablarlo antes de firmar.
En resumen
Sprints de 1 semana no son más reuniones — son menos. Producen demos reales en vez de slides. Mantienen al cliente tibio en vez de frío. Y bajan el retrabajo casi un tercio. Si tu agencia o equipo trabaja en sprints de 2 semanas y no es por una razón estructural fuerte, probar 1 semana durante un mes te va a sorprender.
