Sprint planning cuando no tienes PM dedicado. Te estructura las funcionalidades en historias estimadas y priorizadas.
El prompt
Eres un product manager técnico que ha gestionado sprints en equipos de 3 a 10 developers. Tu sprint planning se caracteriza por historias claras, estimaciones realistas y cero sorpresas a mitad de sprint.
Voy a describir las funcionalidades que necesitamos desarrollar. Organiza un sprint de [1-2 semanas] con:
1. HISTORIAS DE USUARIO: Para cada feature:
- Formato: 'Como [rol], quiero [acción] para [beneficio]'
- Criterios de aceptación (checklist verificable)
- Estimación en story points (1, 2, 3, 5, 8, 13)
- Dependencias con otras historias
2. PRIORIZACIÓN: Ordena por valor de negocio / esfuerzo. Las que dan más valor con menos esfuerzo van primero.
3. RIESGOS: ¿Qué puede salir mal? ¿Hay alguna historia que dependa de un tercero (API externa, decisión de diseño, etc.)?
4. CAPACIDAD: Si el equipo tiene X developers a Y horas, ¿caben todas las historias? Si no, ¿cuáles se quedan fuera?
5. DEFINICIÓN DE DONE: ¿Qué significa que una historia está terminada? (code review, tests, deploy a staging, etc.)
Equipo: [tamaño y seniority]
Duración del sprint: [1 o 2 semanas]
Features: [describir lo que hay que construir]
Cómo usarlo
Modelo recomendado: Cualquiera
Ejemplo de input
Equipo: 2 developers (1 senior, 1 mid). Sprint: 2 semanas. Features: nuevo dashboard de métricas de newsletter, integración con API de Beehiiv, y alertas por email cuando bajan los open rates.
Ejemplo de output
HISTORIA 1 (5 pts): Como editor, quiero ver un dashboard con open rate, CTR y suscriptores activos para tomar decisiones editoriales diarias. Criterios: Datos actualizados cada 4h, gráfico últimos 30 días, responsive mobile. Dependencia: Historia 2 (API Beehiiv).
CAPACIDAD: 2 devs x 2 semanas = ~40 pts disponibles. Total estimado: 34 pts. Cabe todo con 15% de buffer.
Contexto
Cómo planificar un sprint de desarrollo con IA si no tienes PM
En startups de menos de 20 personas, rara vez hay un product manager dedicado. El sprint planning lo hace el CTO, el founder, o directamente los developers. El resultado: sprints sin priorización clara donde se trabaja en lo último que pidió alguien.
Este prompt toma una lista de funcionalidades y las convierte en historias de usuario con criterios de aceptación, estimaciones en story points, dependencias y priorización por valor/esfuerzo.
La parte más útil es el cálculo de capacidad. Le dices cuántos developers tienes y cuánto dura el sprint, y te dice si cabe todo o qué se queda fuera. Mejor saberlo el día 1 que el día 8.
La definición de done es otro punto clave. Si para ti 'terminado' significa código en main y para tu developer significa 'funciona en mi local', tenéis un problema. Este prompt lo explicita desde el principio.