---

machine-translated to es from skills/sprint-planning/SKILL.md — review: pending. Native fixes welcome via PR.

name: sprint-planning description: "Estructura y facilita sesiones de planificación de sprint. Úsalo cuando se te pida planificar un sprint, organizar elementos del backlog, asignar story points, crear objetivos de sprint o preparar agendas de planificación de sprint. Produce un objetivo de sprint, un backlog calibrado por velocidad, un plan de capacidad, señales de riesgo y una agenda estructurada de reunión de planificación de sprint."

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 e hypotheses/ abiertas que el sprint podría probar. Ejecuta python3 ../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.

# 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.