Qué es Scrum, y cuándo conviene no usarlo
Los tres roles, los cinco eventos y los tres artefactos de Scrum explicados sin jerga — y las señales de que tu equipo lo está cargando sin necesitarlo.
Scrum tiene mala fama en algunos equipos, y casi siempre por el mismo motivo: se adoptó el ritual sin el propósito. Daily de pie que dura cuarenta minutos, sprints de dos semanas que nadie cierra a tiempo, un tablero que se actualiza antes de la reunión y no antes. Eso no es Scrum funcionando mal — es teatro con el nombre de Scrum encima.
El marco en sí es corto. Se explica completo en media página. El resto es disciplina de equipo, que ningún proceso reemplaza.
Qué resuelve, en concreto
Scrum existe para un problema específico: construir algo cuyo alcance final no se conoce del todo al principio, entregando valor en el camino en vez de apostarlo todo a una fecha lejana. Si el trabajo es predecible y repetible — instalar el mismo sistema en la sucursal número quince — Scrum no aporta nada que un checklist no resuelva mejor.
La pregunta que decide si aplica
¿El equipo va a aprender algo durante el proyecto que cambie lo que hay que construir? Si sí, entregar en ciclos cortos y ajustar tiene sentido. Si no, Scrum es una capa de reuniones sobre un plan que ya se conocía de entrada.
Los tres roles
- Product Owner. Decide qué se construye y en qué orden, representando al negocio o al cliente. Una sola persona, no un comité — la responsabilidad de priorizar no se reparte sin que se diluya.
- Scrum Master. No es un jefe de proyecto. Protege el proceso: que el equipo pueda enfocarse, que los obstáculos se resuelvan, que las reuniones cumplan su propósito y terminen a tiempo.
- Equipo de desarrollo. Decide cómo se construye. Multidisciplinario y autoorganizado — nadie de afuera le asigna tareas individuales.
Los cinco eventos
| Evento | Para qué sirve | Duración típica |
|---|---|---|
| Sprint | El ciclo completo: planificar, construir, entregar | 1 a 4 semanas, fija |
| Sprint Planning | Elegir qué entra al sprint y cómo se va a abordar | 2 horas por semana de sprint |
| Daily Scrum | Sincronizar al equipo, detectar bloqueos temprano | 15 minutos, de pie |
| Sprint Review | Mostrar lo construido y recoger feedback real | 1 hora por semana de sprint |
| Retrospectiva | Ajustar cómo trabaja el equipo, no qué construye | 45 minutos por semana de sprint |
La Daily es la que más se desvirtúa. No es un reporte de estado para el jefe: es el equipo coordinándose entre sí. Cuando empieza a sentirse como una rendición de cuentas, dejó de cumplir su función.
Los tres artefactos
- Product Backlog. Todo lo que podría construirse, ordenado por prioridad. Vivo — cambia cada vez que se aprende algo nuevo.
- Sprint Backlog. Lo que el equipo se comprometió a entregar en este sprint, más el plan para lograrlo.
- Incremento. Lo que quedó terminado al final del sprint, en condición de poder mostrarse o publicarse — no "casi listo".
Ese último punto es el que más se negocia a la baja. Un incremento que necesita otra semana de ajustes antes de poder mostrarse no es un incremento: es trabajo en curso con una etiqueta encima.
Señales de que se está cargando sin necesitarlo
- El sprint nunca cierra limpio. Si dos de cada tres sprints terminan con tareas que "se pasan al siguiente", el problema no es de disciplina — es que se está prometiendo más de lo que el equipo entrega, sprint tras sprint, sin ajustar la estimación.
- Las reuniones existen porque el calendario las tiene, no porque resuelven algo. Una Daily donde nadie coordina nada, solo informa, es una reunión de estado con otro nombre.
- El Product Owner no tiene autoridad real para priorizar. Si cada decisión de alcance necesita subir tres niveles, el rol es de nombre.
- El equipo es de una o dos personas. Scrum coordina a un equipo. Con una persona, la coordinación no es el problema que hay que resolver.
Cuándo conviene algo más simple
Un tablero Kanban — columnas de estado, trabajo en curso limitado, sin sprints ni ceremonias fijas — suele rendir mejor para soporte, mantenimiento y trabajo que llega de forma continua e impredecible, en vez de por lotes. Y para un equipo de una o dos personas, la disciplina útil es simplemente escribir qué se va a hacer esta semana y revisarlo al final, sin ponerle nombre de marco encima.
Nuestro enfoque
En id3a usamos Scrum en proyectos donde el alcance se descubre en el camino — la mayoría del software a medida entra en esa categoría — y Kanban para mantención y soporte, donde el trabajo llega goteando y no en sprints. La pregunta que hacemos primero no es "¿qué metodología prefieren?", sino "¿qué tan predecible es lo que hay que construir?". La respuesta suele contestar la primera pregunta sola.
¿Te gustó este artículo?
Descubre cómo podemos ayudarte a implementar estas soluciones en tu negocio.