Ir al contenido

Planificar un sprint

Un sprint es un bloque fijo de tiempo dentro de un proyecto: una fecha de inicio, una fecha de fin y el conjunto de tareas comprometidas en él.

Los sprints son opcionales. Si tu equipo tira trabajo de un tablero de forma continua, puedes saltarte esta página entera. Usa sprints cuando quieras una conversación recurrente del tipo “¿a qué nos comprometimos, y lo logramos?”.

Créalo en la sección de sprints del proyecto: dale un nombre, una fecha de inicio y una fecha de fin. Dos semanas es la duración habitual. Una semana funciona si tu trabajo es pequeño y constante; cuatro semanas suele significar que el plan está rancio al llegar al final.

Tira trabajo desde el backlog. Desde una vista de lista puedes seleccionar muchas tareas a la vez y asignarlas todas al sprint, o poner el cursor sobre una tarea y pulsar C.

Dos hábitos hacen que el número final signifique algo:

Estima antes de comprometerte, no después. Una tarea sin estimar cuenta como cero en un gráfico basado en puntos, así que un sprint lleno de trabajo sin estimar parece terminado antes de empezar.

Comprométete a menos de lo que crees. Los dos o tres primeros sprints son medición, no rendimiento. Estás averiguando qué entrega tu equipo de verdad en dos semanas. Ese número casi siempre es menor que el plan, y saberlo es todo el objetivo.

dotby escribe una instantánea del sprint una vez al día, cada día que está abierto. Eso es lo que dibuja el gráfico de burn-up: el alcance comprometido como una línea, el trabajo completado como otra, subiendo hacia ella.

La instantánea diaria importa más de lo que parece. Como cada día se congela cuando ocurre, el trabajo añadido a mitad de sprint sigue visible como un escalón en la línea de alcance en lugar de reescribir la historia en silencio. El crecimiento de alcance aparece como una forma a la que puedes señalar en una retrospectiva.

Cómo leerlo:

  • Completado subiendo firme hacia el alcance — sano.
  • Alcance subiendo también — estáis asumiendo trabajo nuevo a mitad de sprint. A veces es correcto, siempre vale la pena nombrarlo.
  • Completado plano y luego un muro al final — todo terminó el último día, lo que suele significar que las tareas son demasiado grandes para moverse.

Completa el sprint cuando termina el bloque de tiempo — no cuando termina el trabajo. Esa distinción es lo que hace que el número sea honesto.

El trabajo sin terminar no desaparece. Tú decides, tarea por tarea, qué pasa con él: llevarlo al siguiente sprint o devolverlo al backlog. A quien sigue una tarea que termina un sprint sin acabar se le avisa, así que nada se queda en silencio.

Los sprints completados siguen ahí, con sus gráficos intactos. Ese historial es el insumo de planificación más útil que vas a tener — después de tres sprints dejas de adivinar tu capacidad y empiezas a leerla.

Tres formas distintas de agrupar trabajo, fáciles de confundir:

Agrupación Responde Vive en
Sprint Cuándo — en qué bloque de tiempo Un proyecto
Módulo Qué parte — en qué línea de trabajo Un proyecto
Iniciativa Hacia qué resultado Varios proyectos

Una tarea puede estar en un sprint y en un módulo a la vez. Son ejes independientes, no rivales.

  • Proyectos y vistas — guarda una vista “este sprint” para que el equipo tenga un solo sitio donde mirar.
  • Conceptos clave — cómo se relacionan los sprints con todo lo demás.