Hay dos formas típicas de gestionar el trabajo de un equipo, y las dos fallan por motivos opuestos. La primera es no tener ningún proceso: las tareas viven en la cabeza de cada persona, o en un chat que nadie relee, y cada semana se reinventa la prioridad desde cero. La segunda es tener demasiado proceso: reuniones diarias de 45 minutos, retrospectivas eternas y una ceremonia para cada cosa, hasta que el propio proceso se convierte en el trabajo. El objetivo no es elegir entre caos y burocracia; es encontrar el nivel de estructura que tu equipo realmente necesita, y añadirlo en el orden correcto: kanban primero, sprints después, roadmap al final.
Kanban: el punto de partida
Un tablero Kanban resuelve el primer problema real de cualquier equipo: saber qué hay que hacer, quién lo está haciendo y qué está bloqueado. No necesita fechas, ni ciclos, ni estimaciones previas. Sus reglas básicas son pocas:
- Columnas que reflejan el flujo real del trabajo (por ejemplo: por hacer, en curso, en revisión, hecho), no un checklist de fases teóricas que nadie sigue.
- Límites de trabajo en curso (WIP) por columna, para que "en curso" no se convierta en un cementerio de treinta tareas empezadas y ninguna terminada.
- Una tarjeta, una responsabilidad clara. Si nadie es responsable de moverla, no se mueve sola.
Para un equipo pequeño con un flujo de trabajo continuo —soporte, mantenimiento, un solo proyecto activo— el kanban puede ser, literalmente, todo el proceso que necesitan. Añadir más estructura antes de que duela de verdad es la forma más habitual de matar la productividad con buenas intenciones.
Cuándo el kanban se queda corto
El kanban empieza a quedarse corto cuando aparecen dos síntomas a la vez: el equipo gestiona varios proyectos en paralelo, y alguien —un cliente, dirección, ventas— necesita saber cuándo vas a entregar algo, no solo que está "en curso". Un tablero sin ritmo no responde bien a esa pregunta. Ahí es exactamente cuando conviene añadir sprints, no antes.
Sprints: añadir ritmo sin añadir burocracia
Un sprint, reducido a lo esencial, es solo esto: un objetivo compartido, una duración fija y un momento para revisar qué se cumplió. Todo lo demás —planning de dos horas, daily de pie, retro con notas adhesivas— es opcional y depende del tamaño del equipo, no un requisito para que "sea Scrum de verdad".
Un sprint mínimo viable
Así de ligero puede ser un sprint que funcione, sin ceremonia de sobra:
sprint: "Semana 24 — Checkout"
duración: "2 semanas"
objetivo: "Cliente puede pagar con tarjeta sin salir del carrito"
planning: "30 min, lunes"
seguimiento: "Async en el tablero, sin daily obligatoria"
revisión: "30 min, viernes de la segunda semana"Nótese lo que falta a propósito: no hay estimación en puntos de historia, no hay retro de una hora, no hay burndown chart que nadie mira. Se puede añadir cualquiera de esos elementos más adelante, cuando el equipo sienta que le falta — no antes, "porque toca" según algún manual.
Roadmap: conectar el día a día con la estrategia
Si el sprint responde a "¿qué vamos a entregar las próximas dos semanas?", el roadmap responde a una pregunta distinta: "¿hacia dónde vamos los próximos meses?". Un buen roadmap no es una lista interminable de funciones con fecha; es una lista corta de temas o resultados por trimestre (por ejemplo: "reducir el tiempo de onboarding", "lanzar facturación recurrente"), con el margen suficiente para que el equipo decida cómo llegar ahí, sprint a sprint.
La trampa más habitual es tratar el roadmap como un backlog ordenado por fecha. En cuanto una fecha del roadmap se comunica fuera del equipo como una promesa cerrada, deja de ser una herramienta de planificación y se convierte en una fuente de estrés cada vez que algo se retrasa — y algo siempre se retrasa un poco.
Cómo se conectan los tres
La razón por la que kanban, sprints y roadmap suelen vivir en herramientas distintas —y desincronizadas— es que técnicamente son tres vistas del mismo trabajo, no tres sistemas diferentes. Una tarea del tablero puede pertenecer a un sprint activo, y ese sprint puede estar contribuyendo a un tema concreto del roadmap trimestral. Si esa tarea cambia de estado en el tablero, el sprint y el roadmap deberían reflejarlo sin que nadie tenga que actualizar tres sitios a mano.
En Projekt el tablero, el planificador de sprints y el roadmap comparten literalmente las mismas tareas por debajo: mover una tarjeta en el kanban es lo mismo que actualizar el progreso del sprint, que a su vez es lo mismo que actualizar el avance del tema del roadmap. No hay tres fuentes de verdad que sincronizar a mano; hay una sola pieza de trabajo vista desde tres ángulos distintos.
Errores habituales al adoptar este flujo
- Copiar Scrum de un libro sin adaptarlo al tamaño real del equipo. Un equipo de tres personas no necesita las mismas ceremonias que uno de veinte.
- Convertir el roadmap en un backlog con fechas. Un roadmap con demasiado detalle deja de ser estratégico y empieza a generar promesas que luego cuesta cumplir.
- Añadir sprints antes de tener un kanban limpio. Meter ritmo en un flujo de trabajo que ya es caótico solo produce sprints incumplidos, uno tras otro.
- Medir velocidad en lugar de valor entregado. Un sprint "productivo" en puntos que no mueve ningún objetivo del roadmap no ha servido de mucho, por muchos puntos que sume.
Ir de cero proceso a demasiado proceso casi nunca funciona de golpe. Añadir kanban, después sprints y después roadmap —en ese orden, y solo cuando el nivel anterior empieza a quedarse corto de verdad— es la forma más fiable de terminar con un flujo de trabajo que el equipo realmente sigue, en lugar de uno que solo existe en la documentación.