Un tablero visual para la planificación del sprint convierte un objetivo y una lista de historias en un plan que todo el equipo puede revisar. El resultado útil no es un tablero decorativo: muestra el objetivo, el trabajo que cabe, quién coordina cada parte y qué riesgos deben tratarse antes de empezar.
Usa la plantilla de backlog de productos de Boardmix como fuente de historias y crea después una vista específica para el sprint. Un lienzo compartido permite que producto, diseño e ingeniería revisen las mismas suposiciones antes de comprometer el alcance.
Define el resultado del sprint antes de añadir tarjetas
Escribe arriba un resultado en lenguaje sencillo: «Mejorar el primer proyecto para que una persona nueva pueda crear un tablero sin ayuda». Es un filtro para decidir. «Terminar todo el backlog» no lo es. Añade señales de aceptación observables, sin convertirlas en promesas de rendimiento.
Coloca junto al resultado las restricciones que pueden cambiar el plan: una fecha, una dependencia, una revisión o una ventana de mantenimiento. Marca cada una como confirmada, asumida o pendiente. Así un descubrimiento tardío no parece una tarea olvidada.
| Zona | Ejemplo |
|---|---|
| Resultado | Hacer comprensible la configuración del primer proyecto. |
| Evidencia | Revisar observaciones recientes y preguntas de soporte. |
| Restricción | El texto necesita revisión antes de la versión candidata. |
| Decisión abierta | ¿Qué paso de configuración entra en este sprint? |
Haz visible la capacidad sin presentarla como garantía
Crea una zona por equipo o línea de trabajo y añade una nota breve de capacidad para la conversación. La capacidad es un dato de planificación, no un compromiso. Explica si baja por vacaciones, soporte, incorporación u otro trabajo para poder revisarlo cuando cambie el contexto.
Mantén el trabajo no comprometido en un área de candidatos. Una tarjeta puede ser valiosa y aun así quedar fuera del sprint. Separar ambas áreas hace explícita la negociación de alcance.
Divide las historias en trabajo revisable
Empieza por la parte más pequeña que recorra el camino del usuario. «Mejorar el onboarding» es demasiado amplio. Divide en un cambio visible, un comportamiento comprobable y el soporte necesario. No dividas solo por departamento: «escribir», «programar» y «probar» no demuestran que la persona pueda completar la acción.
Usa un formato que muestre el resultado, la evidencia, las condiciones de revisión, la persona coordinadora y las dependencias. La persona responsable coordina el siguiente paso; no significa que haga todo el trabajo.
Planifica riesgos y dependencias junto al trabajo
Traza un conector desde una historia hasta un riesgo cuando la relación sea importante. «Falta una decisión de API», «esperamos contenido» y «la aceptación no está clara» requieren conversaciones distintas. Un riesgo se convierte en acción solo cuando el equipo elige una respuesta.
Si se interrumpe la sesión, deja una marca de «volver aquí» con la pregunta pendiente y las personas que deben responder. Es más útil que ocultar las tarjetas inciertas.
Sigue un orden claro durante la conversación
- Lee el resultado y las restricciones; corrige el tablero antes de hablar del alcance.
- Revisa las tarjetas candidatas y pregunta qué evidencia las justifica.
- Coloca las partes coherentes en las zonas de trabajo.
- Expón dependencias y decide si se resuelven, reducen o aplazan.
- Lee el conjunto como una historia del sprint, no como un recuento de tarjetas.
- Marca las preguntas abiertas y quién aportará la próxima evidencia.
Usa comentarios para preguntas ligadas a una tarjeta y texto o notas para el plan actual. Boardmix ofrece estas piezas de lienzo compartido; el equipo decide qué queda comprometido.
Deja un plan que pueda revisarse después
Conserva vistas de «comprometido», «candidato» y «pendiente». Añade la fecha de la conversación y el próximo punto de revisión. No borres el motivo por el que una tarjeta quedó fuera: evita repetir la misma discusión sin nueva evidencia.
Cuando la estructura esté lista, abre un espacio de Boardmix y adapta el backlog a tu vista de planificación. La plantilla es un punto de partida; el objetivo y las decisiones deben venir de tu equipo.
