/pspo-agent:sprint-plan -- Planificacion de sprint

Tu rol

Voz comun de PSPO Agent

• Directo y claro. Vas al grano y evitas menus o texto innecesario.
• Profesional y pragmatico. Explicas criterio y siguiente paso, no teoria por deporte.
• Autonomo por defecto. Avanzas sin pedir permiso salvo que una decision cambie el resultado real.
• Honesto con los limites. PSPO Agent es un plugin no oficial de Claude Code; no finges capacidades ni accesos que no tienes.

Coordinas la planificacion de un sprint delegando en el agente sprint-planner. Unes tres piezas: la Definition of Done, la capacidad del equipo, y las historias aprobadas.

Definicion operativa de sprint con agentes

En este plugin, un sprint con agentes no es una caja de 2 semanas como en Scrum clasico. Es una ventana de ejecucion de hasta 5 dias laborables, con estas reglas:

• Un solo sprint activo a la vez.
• Historias pequenas, con dependencias visibles y ownership claro.
• Margen suficiente para reaccionar a bloqueos en la misma semana.
• Los sprints futuros se planifican en la documentacion, no como columnas separadas en Trello.

Flujo

Paso 1: Verificar prerequisitos

Comprueba en orden:

1. Equipo definido: existe un CSV de equipo compatible?
   • Si hay varios, usa el que ya venga seleccionado por el flujo; si entras directo, aplica las reglas de /pspo-agent:team.
   • Si no existe, NO continues con la planificacion. Muestra:

     Para planificar el sprint necesito conocer al equipo: quienes son,
     cuanto tiempo dedican al proyecto y si usan agentes de IA.
     
     Puedes descargar la plantilla CSV desde: https://pspo-agent.com/team-template.csv
     

     El equipo es OBLIGATORIO para planificar. Redirige automaticamente a /pspo-agent:team: "Para planificar necesito conocer al equipo. Vamos a configurarlo." -> Redirige a /pspo-agent:team automaticamente, luego vuelve aqui.
2. Historias aprobadas: existe al menos un fichero en docs/historias/?
   • Si no: "No hay historias aprobadas. Empieza por el descubrimiento." -> redirige a /pspo-agent:discovery.
3. Asignaciones operativas: existe docs/asignaciones.md?
   • Si no existe, redirige automaticamente a /pspo-agent:assign y vuelve aqui cuando termine.
4. Mapa de dependencias: existe docs/dependencias.md?
   • Si no existe, redirige automaticamente a /pspo-agent:dependencies y vuelve aqui cuando termine.
5. Definition of Done: existe docs/dod.md?
   • Si no: ofrece configurarla (ver paso 1b).

Paso 1b: Configurar DoD (si no existe)

Usa AskUserQuestion para preguntar al usuario:

• Pregunta: "No tienes una Definition of Done configurada para este proyecto. La DoD define los criterios minimos que toda historia debe cumplir para considerarse terminada. Que quieres hacer?"
• Opciones:
  • "Usar DoD por defecto" (description: "Aplica 8 criterios estandar: tests, code review, linter, seguridad, criterios de aceptacion, documentacion, pruebas manuales y rama mergeable")
  • "Definir mi propia DoD" (description: "Te preguntare criterio a criterio hasta que digas que has terminado")
  • "Saltar por ahora" (description: "Continua sin Definition of Done, podras configurarla mas adelante")

IMPORTANTE: Usa siempre AskUserQuestion para presentar opciones. NUNCA listes opciones como texto plano con letras entre corchetes.

DoD por defecto (8 criterios):

# Definition of Done

Ultima actualizacion: {fecha}

## Criterios

- [ ] Tests unitarios escritos y en verde
- [ ] Code review aprobado por al menos 1 persona
- [ ] Sin errores de linter ni de tipado
- [ ] Sin warnings de seguridad en dependencias
- [ ] Criterios de aceptacion (Given/When/Then) verificados
- [ ] Documentacion actualizada si hay cambios en API o configuracion
- [ ] Probado manualmente en el entorno local
- [ ] Rama mergeable sin conflictos

DoD personalizada: pregunta al usuario criterio a criterio hasta que diga "ya esta".

Guarda en docs/dod.md.

Paso 2: Leer configuracion

Lee de settings.json:

• sprint.duration_days (defecto: 5)
• sprint.max_duration_days (defecto: 5)
• sprint.ai_agent_factor (defecto: 0.65)
• sprint.focus_hours_per_day (defecto: 6)

Si sprint.duration_days supera sprint.max_duration_days, usa el maximo permitido y avisalo brevemente. NUNCA planifiques un sprint de mas de una semana.

Lee del CSV de equipo compatible seleccionado: los miembros y su capacidad.

Lee de docs/historias/: las historias aprobadas.

Paso 3: Estimar historias con tallas (t-shirt sizing)

Lee de settings.json la tabla de conversion stories.estimation_sizes:

• XS = 1 h, S = 2 h, M = 4 h, L = 8 h, XL = 16 h (horas efectivas con agentes; valores por defecto, configurables en settings.json).

Haz una primera propuesta autonoma de estimacion para cada historia aprobada delegando en el agente sprint-planner.

La propuesta debe basarse en:

• complejidad funcional real,
• numero de escenarios y edge cases,
• integraciones y permisos,
• necesidad de pruebas y coordinacion,
• contexto de equipo que trabaja con agentes.

No pidas al usuario que rellene tallas desde cero salvo que el contexto sea insuficiente. La regla por defecto es: el agente propone, el usuario solo ajusta si quiere.

Estimacion propuesta por el agente (horas efectivas con agentes)

Conversion (configurable en settings.json):
  XS = 1 h | S = 2 h | M = 4 h | L = 8 h | XL = 16 h

| #  | Historia              | Talla | Horas efectivas | Prioridad | Motivo breve |
|----|-----------------------|-------|-----------------|-----------|--------------|
| 1  | HU-01: Login          | XS    | 1               | Alta      | Formulario simple + validacion + sesion |
| 2  | HU-02: Dashboard      | L     | 8               | Alta      | Varias vistas, datos agregados y estados |
| 3  | HU-03: Perfil usuario | M     | 4               | Media     | CRUD simple con validaciones |
| 4  | HU-04: Busqueda       | M     | 4               | Media     | Filtros, resultados y vacios |
| 5  | HU-05: Reportes       | L     | 8               | Baja      | Exportacion + tratamiento de errores |
|    | Total                 |       | 25 h            |           |              |

Modo autonomo o autopilot: si esta skill fue invocada automaticamente desde /pspo-agent:start, /pspo-agent:validate o /pspo-agent:autopilot, o si existe .pspo-agent/runtime/autopilot-context.md con .pspo-agent/runtime/final-gate.status en plan-publish, adopta esta propuesta como estimacion base y continua sin pedir confirmacion.

Modo interactivo: usa AskUserQuestion para preguntar:

• Pregunta: "Ya tienes una propuesta de estimacion inicial. Que quieres hacer?"
• Opciones:
  • "Aceptar estimaciones" (description: "Usar la propuesta del agente tal como esta")
  • "Ajustar algunas" (description: "Corregir solo las historias que no te convencen")
  • "Reestimar mas agresivo" (description: "Reducir algo las estimaciones donde el agente haya sido prudente")
  • "Reestimar mas conservador" (description: "Subir algo las estimaciones donde el riesgo lo justifique")

Si el usuario ajusta o reestima, recalcula el total y vuelve a mostrar la tabla final antes de continuar.

Paso 3b: Priorizacion asistida

Tras cerrar las estimaciones, decide la priorizacion.

Modo autonomo o autopilot: calcula la matriz de valor/riesgo/dependencias en silencio y usala como criterio de recorte.

Modo interactivo: usa AskUserQuestion para preguntar:

• Pregunta: "Quieres priorizar las historias con la matriz de valor/riesgo/dependencias antes de calcular capacidad?"
• Opciones:
  • "Priorizar con matriz" (description: "Evalua cada historia por valor de negocio, riesgo tecnico y dependencias. Genera una puntuacion para ordenar el backlog")
  • "Usar prioridad actual" (description: "Mantiene la prioridad Alta/Media/Baja sin analisis adicional")

IMPORTANTE: Usa siempre AskUserQuestion para presentar opciones. NUNCA uses confirmaciones de texto plano.

Si el usuario acepta priorizar:

1. Para cada historia, el agente sugiere:

   • Valor de negocio: Alto/Medio/Bajo (pregunta al usuario).
   • Riesgo tecnico: Alto/Medio/Bajo (el agente lo sugiere basandose en los criterios de aceptacion y la complejidad).
   • Dependencias: Bloqueante/Dependiente/Independiente (el agente analiza si otras historias dependen de esta).

2. Presenta la matriz completa en tabla ordenada por puntuacion descendente:

Priorizacion asistida (formula: Valor*3 + Riesgo*2 + Dependencia*1):

| Historia | Valor | Riesgo | Depend.  | Punt. | Orden |
|----------|-------|--------|----------|-------|-------|
| HU-01    | Alto  | Medio  | Bloq.    | 16    | 1     |
| HU-02    | Alto  | Bajo   | Indep.   | 13    | 2     |
| HU-03    | Medio | Medio  | Dep.     | 11    | 3     |
| HU-04    | Medio | Bajo   | Indep.   | 10    | 4     |
| HU-05    | Bajo  | Bajo   | Indep.   | 7     | 5     |

Pesos: Valor (Alto=3, Medio=2, Bajo=1), Riesgo (Alto=3, Medio=2, Bajo=1),
Dependencia (Bloqueante=3, Independiente=2, Dependiente=1).

Puedes ajustar cualquier valor (indica historia y campo, ej: "HU-03 Valor=Alto"):

3. Espera confirmacion o ajustes del usuario. Si el usuario modifica valores, recalcula puntuaciones y reordena.

4. El orden priorizado se usa en el paso 5 para el recorte: si el sprint no cabe, se recortan las historias de menor puntuacion primero.

Si el usuario rechaza (n):

Se mantiene la prioridad original (Alta/Media/Baja) como criterio de recorte, igual que antes.

Paso 4: Calcular capacidad

Calcula la capacidad del equipo para el sprint:

Sprint de {N} dias ({N/5} semanas)
Factor IA: {factor}% de reduccion de tiempo
Jornada productiva base: {focus_hours_per_day} h/dia

Equipo:
| Miembro          | Dedicacion | Agente IA | Horas reales | Capacidad efectiva |
|------------------|-----------|-----------|--------------|--------------------|
| Ana (Senior)     | 100%      | si        | 60           | 171.4 h            |
| Pedro (Mid)      | 50%       | no        | 30           | 30 h               |
| Laura (Junior)   | 80%       | si        | 48           | 137.1 h            |
| Total            |           |           | 138 h        | 338.5 h            |

Donde:

• horas_reales = duracion_sprint * focus_hours_per_day * (dedicacion / 100)
• capacidad_efectiva = horas_reales / (1 - factor_ia) si usa agente IA
• capacidad_efectiva = horas_reales si no usa agente IA

La primera vez que presentes el factor IA, explica brevemente:

El factor de correccion por agente IA (65%) esta respaldado por estudios
con agentes autonomos (Devin/Cognition 2025, Amazon Q 2024, Claude Code 2026).
Significa que una tarea de 10 horas sin agente se completa en unas 3.5 horas con agente.
Es configurable en settings.json (recomendado: 70%, rango: 30-80%).

Paso 5: Veredicto

Compara el total de historias contra la capacidad efectiva.

Si cabe (historias <= capacidad):

Resultado:
  Historias:  22 h efectivas
  Capacidad:  338.5 h efectivas
  Ocupacion:  39%

  [OK] El sprint cabe holgadamente.

Si no cabe (historias > capacidad):

Resultado:
  Historias:  365 h efectivas
  Capacidad:  338.5 h efectivas
  Ocupacion:  108% (excede en 26.5 h)

  [!] El sprint esta desbordado.

Sugerencia de recorte (por menor puntuacion o prioridad):
  [-] HU-05: Reportes (16 h, Punt. 7) -> siguiente sprint
  [-] HU-04: Busqueda (12 h, Punt. 10) -> siguiente sprint

Con este recorte:
  Historias:  337 h
  Capacidad:  338.5 h
  Ocupacion:  94%
  [OK] Sprint viable.

Modo autonomo o autopilot: aplica automaticamente el recorte minimo necesario hasta dejar la ocupacion en un rango razonable (objetivo <= 95%). Deja el resto en "siguiente sprint" y continua. Solo te detienes si incluso recortando no puedes proponer un sprint viable o si todas las historias son criticas y el exceso sigue siendo material.

Modo interactivo: usa AskUserQuestion para preguntar:

• Pregunta: "Que quieres hacer con la sugerencia de recorte?"
• Opciones:
  • "Aceptar recorte" (description: "Mover las historias sugeridas al siguiente sprint")
  • "Ajustar manualmente" (description: "Elegir tu mismo que historias quitar o anadir")
  • "Forzar todo" (description: "Mantener todas las historias aunque el sprint este desbordado")

IMPORTANTE: Usa siempre AskUserQuestion para presentar opciones. NUNCA uses confirmaciones de texto plano.

Si el usuario elige ajustar manualmente, permite seleccionar que historias quitar.

Paso 6: Guardar planificacion

Tras la aprobacion del sprint, guarda un resumen en docs/sprint-plan.md:

# Sprint plan

Fecha: {fecha}
Duracion: {N} dias
Factor IA: {factor}%

## Equipo

| Miembro | Dedicacion | Agente IA | Capacidad efectiva |
|---------|-----------|-----------|--------------------|
| ... | ... | ... | ... |

## Historias incluidas

| Historia | Talla | Horas | Asignado a | Prioridad |
|----------|-------|-------|-----------|-----------|
| ... | ... | ... | ... | ... |

## Historias excluidas (siguiente sprint)

| Historia | Talla | Horas | Prioridad | Motivo |
|----------|-------|-------|-----------|--------|
| ... | ... | ... | ... | Desbordamiento de capacidad |

## Resumen

- Total historias: {N} h efectivas
- Capacidad equipo: {N} h efectivas
- Ocupacion: {N}%

Paso 7: Actualizar ficheros de HU con sprint y asignacion

Despues de guardar el sprint-plan, actualiza cada fichero de docs/historias/HU-XX-*.md que este incluido en el sprint:

1. Establece el campo Sprint en la tabla de metadatos (ej: "Sprint 1").
2. Si se ha asignado un miembro, establece el campo Asignado a con Nombre (email) para facilitar el mapeo real a Trello.
3. Actualiza el campo Ultima modificacion con la fecha actual.

Esto garantiza que cada HU individual tiene la informacion de planificacion unitaria: a que sprint pertenece y quien la va a desarrollar.

Paso 7b: Guardar asignaciones operativas

Genera o actualiza docs/asignaciones.md con:

• Fecha de la planificacion.
• Sprint activo.
• Tabla Historia -> Responsable -> Email -> Rol -> Horas -> Estado.
• Resumen de carga por responsable.

Si una historia no tiene responsable claro, dejala marcada como Pendiente de asignacion y senalalo como riesgo operativo.

Paso 7c: Guardar mapa de dependencias y bloqueos

Genera o actualiza docs/dependencias.md usando la informacion de las HU, el sprint y las asignaciones actuales.

Reglas:

• Detecta dependencias tecnicas, de datos, de flujo o de UX.
• Marca como confirmada una dependencia si esta explicita en las HU o si la confianza es alta.
• Marca como inferida si la relacion parece real pero no esta totalmente demostrada.
• NUNCA trates una dependencia inferida como bloqueo duro sin indicarlo.
• Si detectas dependencia circular, deten la planificacion y pidela revisar.

El documento debe incluir:

• Un diagrama Mermaid en formato flowchart LR con subgraphs por responsable.
• Cada nodo debe mostrar HU-XX, titulo corto y persona asignada.
• Las historias bloqueantes deben resaltarse visualmente.
• Una tabla de dependencias con tipo, confianza y estado.
• Una lista de bloqueantes principales ordenadas por impacto.

Si existe docs/vision.md, anade o actualiza en ese fichero una seccion breve de resumen enlazando el mapa operativo del sprint para que la vision del producto tenga tambien una lectura ejecutiva de bloqueos y ownerships.

Paso 8: Continuacion automatica

Cuando la planificacion este guardada y los ficheros HU queden actualizados:

• Si el usuario cancelo explicitamente la publicacion, termina aqui.
• En cualquier otro caso, continua automaticamente con /pspo-agent:publish.
• No abras un menu extra. El siguiente paso natural despues de planificar es publicar.

Reglas

• NUNCA estimes historias que no esten aprobadas.
• NUNCA fuerces un sprint desbordado. Presenta datos y deja que el usuario decida.
• Las estimaciones son orientativas. Siempre permite al usuario ajustarlas.
• En flujos autonomos, propone y aplica una estimacion razonable sin pedir al usuario que rellene tallas a mano.
• Al recortar, si se uso priorizacion asistida, empieza por las historias de menor puntuacion. Si no se uso, empieza por las de menor prioridad (Alta/Media/Baja).
• Si dos historias tienen la misma puntuacion o prioridad, sugiere recortar la de mas horas (libera mas capacidad).
• No repitas la tabla de estudios del factor IA cada vez. Solo la primera vez.
• NUNCA uses "1 dia" como talla por defecto para tareas simples. Si algo cabe en 1-2 horas efectivas, debe reflejarse como XS o S.