Skill de Planificación de Sprint
Transforma elementos crudos del backlog en un sprint estructurado y alcanzable con objetivos claros, alcance calibrado por velocidad y resultados listos para el equipo.
Lee de / Escribe en el Brain
Si existe un professional-brain (brain/), fundamenta en él en lugar de volver a preguntar lo que ya sabes:
- Lee primero:
decisions/prioritarias (lo que el equipo acordó que importa),entities/de features ehypotheses/abiertas que el sprint podría probar. Ejecutapython3 ../professional-brain/scripts/brain_query.py ./brain "<sprint goal>"y lleva la etiqueta de procedencia de cada hecho a través del proceso. - 📥 Propón al Brain: después de producir, propón registrar el compromiso del sprint (objetivo + alcance comprometido) como un registro
decisions/, etiquetado con procedencia. Muéstralo, obtén un sí, luego escribe con../professional-brain/scripts/brain_write.py … --commit(solo anexar, seco por defecto).
Propone Acciones
Una vez que el sprint sea acordado, entrégalo a action-runner: vista previa (seco, evaluado por riesgo), ejecuta solo lo que apruebes a través del MCP de acción conectado, y registra lo que se hizo de vuelta al brain. Típico: crear un ticket por elemento de backlog comprometido y establecer el hito del sprint (🟡). Esta skill propone; action-runner vigila y ejecuta — nunca silenciosamente.
Lo Que Esta Skill Produce
- Objetivo de Sprint — oración única, enfocada en resultados, que todo el equipo pueda impulsar
- Backlog del Sprint — lista priorizada de historias de usuario con estimaciones de story points y criterios de aceptación
- Plan de Capacidad — desglose de disponibilidad del equipo considerando vacaciones, reuniones y tiempo de enfoque
- Agenda de Planificación de Sprint — agenda de reunión estructurada de 2 horas con tiempos
- Señales de Riesgo — bloqueadores o dependencias que podrían descarrilar el sprint
Entradas Requeridas
Pregunta por (si no se proporciona ya):
- Duración del sprint (1 o 2 semanas)
- Tamaño del equipo y velocidad (promedio de story points por sprint)
- Top 3–5 elementos del backlog o épicas de los que tirar
- Cualquier ausencia conocida, vacaciones o eventos del equipo
- Elementos incompletos del sprint anterior (carryovers)
Fórmula de Objetivo de Sprint
Usa esta estructura:
"En este sprint entregaremos [resultado X] para que [beneficio de usuario/negocio], medido por [indicador de éxito]."
Nunca escribas objetivos de sprint como listas de tareas. Siempre primero los resultados.
Calibración de Story Points
| Complejidad | Points | Descripción |
|---|---|---|
| Trivial | 1 | Claramente entendido, sin incógnitas |
| Pequeño | 2 | Sencillo, esfuerzo menor |
| Medio | 3 | Cierta complejidad, camino claro |
| Grande | 5 | Complejo, necesita diseño o investigación |
| Muy Grande | 8 | Alta incertidumbre, puede necesitar dividirse |
| Épica | 13+ | Demasiado grande — debe dividirse antes del sprint |
Marca cualquier elemento estimado en 8+ y recomienda dividirlo.
Fórmula de Capacidad
Capacidad disponible = (Tamaño del equipo × Días del sprint × Horas de enfoque/día) × Factor de disponibilidad Horas de enfoque/día: 6 (considerando reuniones, Slack, admin) Factor de disponibilidad: 0.7–0.85 dependiendo de vacaciones/eventos Story points a comprometer = Velocidad histórica × Factor de disponibilidad
Helper Programático
Esta skill incluye un script Python solo con stdlib que calcula capacidad en lugar de estimarla a mano. Úsalo siempre que se conozcan los números del equipo — aplica las reglas de disponibilidad y ratio de compromiso del 80% de forma consistente.
bash# Estimación rápida desde banderas python3 scripts/capacity_calculator.py --team 5 --days 10 --velocity 30 --availability 0.8 --carryover 5 # Estimación detallada desde disponibilidad por miembro (JSON vía stdin o archivo --input) echo '{"sprint_days":10,"historical_velocity":40,"carryover_points":8, "members":[{"name":"Ada","available_days":10},{"name":"Linus","available_days":7}]}' \ | python3 scripts/capacity_calculator.py --input -
El script retorna horas de enfoque disponibles, una figura de velocidad ajustada por disponibilidad real, el compromiso recomendado (limitado al 80% de velocidad), y la capacidad restante para trabajo nuevo después de carryovers. Ejecútalo primero, luego construye el backlog del sprint para encajar el número recomendado. Añade --json para canalizar el resultado en otras herramientas.
Formato de Salida
Sprint [N] — [Fecha de inicio] a [Fecha de fin]
Objetivo del Sprint:
[Declaración de objetivo]
Capacidad del Equipo: [X] story points disponibles (basado en [Y] miembros del equipo, [Z]% disponibilidad)
Backlog del Sprint:
| Prioridad | Historia | Points | Owner | Criterios de Aceptación |
|---|---|---|---|---|
| 1 | [Título de historia] | [N] | [Miembro del equipo] | [Cuando X entonces Y] |
Carryovers del Sprint Anterior:
- [Elemento] — Razón del carryover: [breve explicación]
Riesgos y Dependencias:
- [Descripción de riesgo] → Mitigación: [acción]
Agenda de Planificación de Sprint:
- 00:00–00:10 — Revisar objetivo del sprint y capacidad del equipo
- 00:10–00:40 — Recorrer elementos del backlog, confirmar estimaciones
- 00:40–01:20 — Asignar historias, identificar dependencias
- 01:20–01:50 — Revisar criterios de aceptación por historia
- 01:50–02:00 — Confirmar compromiso del sprint y cerrar
Pautas
- Siempre cuestiona historias sin criterios de aceptación — márcalas explícitamente
- Recomienda que el equipo se comprometa al 80% de capacidad disponible, no 100%
- Si no se proporcionan datos de velocidad, asume 20–30 points para un equipo de 5 personas como punto de partida
- Destaca cualquier historia con propiedad poco clara como bloqueador
Controles de Calidad
- El objetivo del sprint es enfocado en resultados (no "implementar X" — algo como "los usuarios pueden hacer Y")
- La capacidad del equipo se calcula usando disponibilidad real, no teórica 100%
- Cada historia tiene un criterio de aceptación (marca cualquier que no lo tenga)
- Las historias estimadas en 8+ points se marcan para dividirse
- Los carryovers del sprint anterior se consideran en la capacidad
Anti-Patrones
- No escribas objetivos de sprint como listas de tareas — los objetivos deben ser enfocados en resultados y evaluables como aprobado/reprobado al final del sprint
- No te comprometas al 100% de capacidad disponible — siempre recomienda 80% para preservar margen para trabajo no planificado
- No lleves historias sin criterios de aceptación al sprint — márcalas como bloqueadores antes de comprometerte
- No permitas historias estimadas en 8+ points en el sprint sin dividirlas primero
- No ignores elementos carryover cuando calcules capacidad — consumen capacidad y deben considerarse antes de traer trabajo nuevo
Ejecución
Para agentes que usan herramientas o acceso a computadora que pueden alcanzar el tracker del equipo (Jira, Linear, GitHub Projects). Los runtimes sin acceso a herramientas ignoran esta sección y entregan el documento. Ver SKILLSPEC.md §5 para las reglas que sigue este bloque.
Precondiciones
- El plan del sprint anterior ha sido producido y explícitamente aprobado por un humano — nunca construyas un sprint desde un borrador sin revisar.
- El acceso al tracker ya está autenticado en el entorno del agente; la placa/proyecto objetivo se nombra por el usuario.
- Un listado en seco de cambios previstos ha sido mostrado y confirmado.
Acciones permitidas
- Crear el contenedor de sprint/iteración con el nombre y fechas aprobados.
- Mover los elementos del backlog ya existentes y aprobados al sprint — solo los elementos listados en el plan aprobado.
- Establecer estimaciones de story points en esos elementos a los valores aprobados.
- Publicar el objetivo del sprint como descripción del sprint o comentario fijado.
- Nada más: sin crear nuevos issues, sin eliminar o cerrar nada, sin editar descripciones de elementos, sin tocar otros sprints.
Verificación
- Re-lee el sprint desde el tracker: el conteo de elementos y puntos totales igual el plan aprobado; cada elemento movido está en el sprint; las fechas del sprint coinciden.
- Publica el resumen de verificación (elementos, points, fechas) de vuelta al usuario.
Rollback
- Deshacer = mover los elementos de vuelta al backlog y eliminar el contenedor de sprint vacío.
- Para y pregunta a un humano si: cualquier elemento en el plan ya no existe o cambió desde la aprobación, el tracker rechaza una acción, o la placa contiene un sprint activo con fechas superpuestas.
