Las reuniones de equipo breves y útiles tienen tres cosas en común: una agenda por escrito con un tiempo asignado a cada punto, un final claro y un resultado sobre el que alguien actúa. La planificación realista de sprints tiene una más: el equipo se compromete con lo que sus sprints recientes dicen que puede hacer, ajustado según quién está realmente disponible, y no con lo que espera conseguir.
La mayoría de los equipos no empiezan con reuniones largas, sino que acaban teniéndolas poco a poco: el standup se convierte en un informe de estado, los problemas se resuelven en el corro mientras seis personas esperan y la planificación se transforma en una negociación que gana la estimación más optimista. Esta guía explica cómo solucionarlo en cuatro pasos, con cuatro herramientas gratuitas de kimisuite.com. Ninguna requiere cuenta.
Paso 1: Escribe la agenda antes de enviar la invitación
El Meeting Agenda Generator ofrece seis plantillas: daily standup, retrospectiva de sprint, all-hands, reunión 1:1, llamada de descubrimiento comercial y kickoff de proyecto. Introduces un título, la duración de la reunión y el nombre de quien la facilita, y copias o descargas el resultado en markdown.
La plantilla de standup tiene este aspecto:
- Ayer: logros y bloqueos (5 min)
- Hoy: prioridades (5 min)
- Bloqueos y peticiones (5 min)
- Algo que nadie sabe (una ronda de un minuto)
La plantilla de retrospectiva dura 42 minutos: preparar el contexto (5), qué fue bien (10), qué no fue bien (10), acciones concretas, con responsable y fecha límite (15), y un rápido chequeo de energía del 1 al 5 (2).
Un detalle que conviene saber: los tiempos de cada sección son fijos en cada plantilla. La duración que escribes aparece en el encabezado, pero las secciones no se reajustan. Si tu retro dura 30 minutos, acórtalas a mano antes de enviar la invitación. Precisamente esa edición es lo importante: decides de antemano a qué le dedicas menos tiempo.
Paso 2: Limita el standup a 15 minutos
La Guía de Scrum (versión de noviembre de 2020, scrumguides.org) describe el Daily Scrum como "un evento de 15 minutos para los Developers", celebrado "a la misma hora y en el mismo lugar cada día laborable del Sprint". Su objetivo es inspeccionar el progreso hacia el Sprint Goal y adaptar el plan para el trabajo que viene.
La misma guía dice también que los Developers "pueden elegir la estructura y las técnicas que quieran". Las tres preguntas clásicas son una costumbre, no una regla. Si "¿qué hiciste ayer?" se ha convertido en una letanía, cambia la pregunta.
Aquí resulta útil el Standup Question Generator. Elige entre 1 y 10 preguntas al azar de uno de sus cuatro bancos: rompehielos, retrospectiva, profundas y divertidas. Abre el standup una vez por semana con una pregunta rompehielos, o lleva a la retrospectiva preguntas como "¿Dónde perdiste más tiempo?" o "¿Qué tenemos que DEJAR de hacer?".
Paso 3: Estima las historias antes de planificar
La planificación es más rápida cuando las historias ya tienen tamaño. El Story Point Estimator es una versión individual del planning poker. Eliges Fibonacci (1, 2, 3, 5, 8, 13, 21, 40, 100) o tallas de camiseta (de XS a XXL, más "?"), escribes la historia, eliges una carta y fijas tu nivel de confianza en bajo, medio o alto. Las estimaciones se van añadiendo a una lista con el total de puntos.
Lo más útil son las indicaciones bajo cada carta. Un 13 muestra "Grande · divídela antes de comprometerte", un 21 "Demasiado grande · divídela en historias más pequeñas", y "?" significa que necesitas más información antes de estimar. Si te ves eligiendo 13 o más, la historia no está lista para el sprint.
Las estimaciones individuales son un punto de partida. El equipo debe comentarlas igualmente, porque una sola persona no sabe lo que saben las demás.
Paso 4: Prevé el sprint a partir de tu propia velocidad
La Guía de Scrum no menciona la velocidad ni los story points. Sí dice que cuanto más sepan los Developers sobre "su rendimiento pasado, su capacidad futura y su Definition of Done, más confianza tendrán en sus previsiones del Sprint". La velocidad, es decir, los puntos que un equipo completa por sprint, es una forma habitual de medirlo.
La Sprint Velocity Calculator toma tus tres últimos sprints y tu capacidad para el siguiente, en porcentaje, y devuelve:
- La media de los tres sprints
- Una tendencia: al alza si el último sprint superó en más de un 10 por ciento al anterior, a la baja si quedó más de un 10 por ciento por debajo y, en caso contrario, estable
- Una previsión: la media multiplicada por tu capacidad
- Cuántos sprints hacen falta para completar 50 puntos con esa previsión
Un ejemplo práctico
Un equipo de cinco personas completó 24, 31 y 27 puntos en sus tres últimos sprints. Una persona estará de vacaciones durante todo el próximo sprint, así que la capacidad es del 80 por ciento.
- Media: (24 + 31 + 27) / 3 = 27,3 puntos
- Tendencia: 27 está más de un 10 por ciento por debajo de 31, así que la calculadora muestra "Tendencia a la baja: revisa los bloqueos"
- Previsión: 27,3 x 0,8 = 21,8 puntos
- Sprints para completar 50 puntos: 50 / 21,8 = 2,3, redondeado a 3
Ahora toma las historias estimadas en el paso 3: 8, 5, 5, 3 y 2 puntos, 23 en total. Es más que la previsión de 21,8. El plan honesto es 8 + 5 + 5 + 3 = 21 puntos, con la historia de 2 puntos como la primera que se incorpora si el equipo termina antes.
La tendencia solo compara los dos últimos sprints, así que basta un sprint complicado para que aparezca "a la baja". Antes de interpretarlo como un problema, pregunta en la retrospectiva qué se interpuso. Y nunca compares la velocidad entre equipos: los puntos de cada equipo significan algo distinto.
Dónde encaja KIMISUITE
Las herramientas funcionan por sí solas. Si quieres tener las reuniones y el tablero del sprint en un mismo lugar, dos apps de KIMISUITE cubren los pasos anteriores.
Meeting Hub gestiona videollamadas a las que los invitados se unen desde el navegador con un enlace. Al programar una reunión, puedes pegar la agenda en su descripción. Durante la llamada, el menú Herramientas incluye un temporizador (1, 5, 10, 15 o 30 minutos, o personalizado) que todos ven y que se pone en rojo al llegar a 0:00. Una encuesta con dos o más opciones ayuda a decidir en la retro qué acción abordar primero. Después de la reunión, la transcripción se puede descargar en todos los planes y, en Pro y Enterprise, un resumen con IA recoge las acciones, con responsable y fecha, y las decisiones tomadas.
Task Hub alberga el propio sprint. Su plantilla Engineering Sprint crea listas, etiquetas y tarjetas de ejemplo para un tablero nuevo. Desde el plan Grow, puedes añadir campos personalizados, como un campo numérico, y definir dependencias, de modo que una tarjeta muestre qué bloquea o qué la bloquea. En el plan Business, AI Task puede convertir el resumen y la transcripción de una reunión finalizada de Meeting Hub en propuestas de tarjetas, que revisas antes de que se creen. Más sobre este flujo en Task Hub: de una nota de voz a un tablero de tareas.
Ambas apps están en el mismo espacio de trabajo de KIMISUITE, que se factura por espacio de trabajo, no por usuario. Para ver qué supone esto para un equipo, consulta precio por espacio de trabajo, no por usuario. Cada app incluye una prueba de 14 días.
Preguntas frecuentes
¿Y si nuestro standup sigue pasando de 15 minutos?
Saca de él la resolución de problemas. Cuando un tema necesite más de un minuto, menciónalo, indica las dos personas que deben hablarlo y deja que se reúnan justo después.
¿Tenemos que usar las tres preguntas del standup?
No. La Guía de Scrum de 2020 permite que los Developers elijan la estructura, siempre que la reunión inspeccione el progreso hacia el Sprint Goal y adapte el plan. Una pregunta distinta cada semana evita que la ronda se convierta en un informe.
¿Cuántos sprints necesito para calcular la velocidad?
La Sprint Velocity Calculator usa los tres últimos. Con menos sprints, la media es poco fiable; los sprints muy antiguos describen un equipo que puede haber cambiado desde entonces.
¿Qué capacidad debo introducir si alguien falta parte del sprint?
Calcula qué parte de los días laborables del equipo está realmente disponible. En un equipo de cinco, una persona ausente todo el sprint supone un 80 por ciento. Una persona ausente tres días de un sprint de diez supone 47 de 50 días-persona, es decir, alrededor del 94 por ciento.
