sprint-planning

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](../professional-brain/SKILL.md) (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](../action-runner/SKILL.md): 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](../../SKILLSPEC.md) 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.