El Sprint 0: ¿habitual o un mito?

Aunque no figure en la Guía oficial de Scrum, el Sprint 0 es sumamente común y, en la mayoría de los casos, necesario. ¿Es tu caso?

• ¿Es habitual? Sí. En proyectos complejos donde no hay nada montado, es casi un estándar de la industria.
• ¿Para qué sirve? No se trata de desarrollar funcionalidades del producto, sino de preparar el terreno. Se enfoca en:
  • Configuración de entornos (Dev, Staging, Prod).
  • Definición de la arquitectura base.
  • Instalación de herramientas de CI/CD.
  • Creación del Initial Product Backlog.
  • Alineación de la visión del equipo (acordar el Definition of Done o el Definition of Ready).

Ojo: El peligro del Sprint 0 es que se convierta en una fase eterna de «análisis» que dure meses. En agilidad, debe ser corto (una o dos semanas máximo) para habilitar al equipo a entregar valor real en el Sprint 1.

---

El informe técnico de anteproyecto

En algunos proyectos se suele elaborar un informe técnico para entregar al equipo, y algo importante a mencionar aquí a modo de recomendación: no debe ser un documento estático ni excesivamente burocrático.

En agilidad lo llamamos a menudo Product Inception o Discovery Document. Es una excelente práctica porque:

• Evita el «teléfono descompuesto»: Provee al equipo técnico un contexto claro de qué se quiere resolver y bajo qué restricciones tecnológicas.
• Reduce la incertidumbre: Al equipo no se le puede tirar un «hagan una app» sin lineamientos. Este informe debe incluir:
  • Objetivos del negocio: El «por qué» hacemos esto.
  • Stack tecnológico sugerido/obligatorio: ¿Usaremos Python, Node, React? ¿Qué bases de datos?
  • Integraciones: ¿Hay que pegarse a una API de terceros o a un sistema legado?
  • Diagramas de alto nivel: Arquitectura, flujos de usuario críticos.

Cómo entregarlo sin ser «Waterfall»

La clave es que este informe sea el punto de partida para una conversación, no una ley grabada en piedra. El equipo debe poder cuestionar lo técnico y proponer mejoras durante el refinamiento.

Práctica	¿Es recomendada?	Motivo Principal
Sprint 0	Altamente común	Prepara la infraestructura y alinea al equipo sin la presión de entregar «features» el día uno.
Informe Técnico	Buena práctica	Garantiza que el equipo no empiece a ciegas y entienda los límites del sistema.

---

Planteo de la situación

Tengo que analizar un informe de anteproyecto que me han entregado para la próxima reunión de Sprint 0 que tendremos con el equipo de proyecto en el que se tratarán todos los aspectos del producto que se deberá desarrollar a lo largo de los diferentes sprints que se definirán. Estoy a cargo de la gestión del testing del proyecto y por lo tanto necesito conocer cuál es la mejor práctica por aplicar y que prompt framework puede implementar. ¿Qué me recomiendas para poder analizar el informe y además estar preparado para participar activamente en la reunión?

Devolución de mi Asistente-IA

Voy a apoyarme en la base cargada para aterrizar la recomendación a tu caso de Sprint 0, en vez de darte una respuesta genérica. Buscaré la mejor práctica de gestión de testing y el framework de prompt más alineado.

Ya ubiqué el núcleo de la recomendación: para tu caso no alcanza con “leer el informe”, conviene preparar desde ahora un paquete de planificación de prueba, mapa de implicados y priorización por riesgo para Sprint 0. Voy a extraer los pasajes más útiles para sustentarlo bien.

1. Diagnóstico de la situación

Estás ante una situación típica de arranque de proyecto con foco en Sprint 0, donde tu problema real no es solo “leer un informe”, sino transformar ese anteproyecto en una base de decisiones de testing: entender contexto, alcance, objetivos de calidad, implicados, riesgos, enfoque de prueba y condiciones para planificar los primeros sprints. ISTQB Test Management sitúa precisamente ahí el trabajo del Test Manager: la planificación de la prueba debe empezar lo antes posible, incluso para una iteración o sprint, y debe incluir comprensión del contexto, análisis de riesgos, definición del enfoque y asignación de recursos.

Clasifico tu situación como una combinación de estas categorías: planificación, estrategia de pruebas, análisis de riesgos, comunicación con stakeholders y, en menor medida, requerimientos. Además, para participar activamente en la reunión no basta con revisar el documento: necesitas llegar con una posición de QA preparada, apoyada en un análisis de implicados y en una priorización temprana por riesgo. ISTQB indica que los implicados deben analizarse como parte de la estrategia y del plan de prueba, y que su conocimiento influye en la gestión de expectativas, la mitigación de riesgos y la toma de decisiones.

2. Mejor práctica recomendada

La mejor práctica principal que te recomiendo es aplicar una planificación temprana de pruebas basada en contexto + implicados + riesgos. En términos prácticos, antes de la reunión deberías convertir el informe en estos cinco insumos mínimos:

1. alcance y objetivos de calidad preliminares,
2. mapa de implicados y conocimiento que aportan,
3. riesgos iniciales de producto y de proyecto,
4. enfoque de prueba preliminar por prioridades,
5. lista de preguntas y decisiones que QA debe llevar a Sprint 0. Esto está alineado con ISTQB TM, que define la planificación temprana como comprensión del contexto, análisis de riesgos, tratamiento del riesgo, definición del enfoque y asignación de recursos.

Como prácticas complementarias, te conviene:

• usar una matriz de poder-interés para saber a quién involucrar y con qué nivel de detalle,
• capturar el tipo de conocimiento que cada implicado aporta a la estrategia de prueba,
• priorizar el esfuerzo inicial mediante Risk-Based Testing (RBT), y
• si el proyecto termina siendo más híbrido que puramente Scrum, adaptar desde el inicio tu lenguaje y reporting entre lo ágil y lo más formal. La BCU refuerza esto al pedir explícitamente lista de implicados, conocimiento aportado, riesgos actuales, canales de comunicación y, para RBT, backlog, riesgos priorizados, roles, plazo y trazabilidad riesgo → prueba.

3. Prompt Framework recomendado

El framework principal que te recomiendo es una combinación de:

Framework principal:
Context priming + Instructional scaffolding sobre el prompt de “Importancia del conocimiento de los implicados en la gestión de la prueba”. Lo elijo porque tu necesidad inmediata no es todavía construir un plan de ejecución detallado, sino extraer del informe lo que QA necesita saber para influir en la estrategia, priorización y comunicación desde Sprint 0. La BCU lo orienta exactamente a eso: identificar qué sabe cada implicado, cómo impacta en la estrategia, cómo obtener esa información y cómo adaptar la comunicación.

Frameworks combinables:
Verification & refinement loop + Role prompting. Son muy útiles porque no solo generan el análisis, sino que luego lo someten a una revisión de completitud y a una “auditoría externa simulada”, ideal para llegar a la reunión con lagunas ya detectadas y una lista priorizada de ajustes.

Combinación adicional recomendada según tu caso:
Añadir el framework de RBT + Cuadrantes de Prueba como segunda capa. Esto te permite pasar de “entender el informe” a “proponer prioridades concretas de testing” para Sprint 0 y primeros sprints, evitando un enfoque genérico o checklist rígido. La BCU lo plantea justo así: cuadrantes para estructurar y RBT para decidir dónde invertir primero el esfuerzo según probabilidad e impacto.

4. Justificación basada en la BCU

La recomendación se apoya directamente en el material cargado:

ISTQB Test Management establece que la planificación de la prueba aplica también a una entrega, iteración o sprint, debe comenzar temprano y contempla comprender contexto, identificar y analizar riesgos, seleccionar tratamientos del riesgo, definir enfoque y recursos, y lograr aceptación por los implicados. Eso encaja exactamente con tu necesidad previa a Sprint 0.

El mismo syllabus indica que el Test Manager debe realizar un análisis de implicados como parte de la estrategia y del plan de prueba, y utilizar una matriz de poder-interés para priorizar el involucramiento y gestionar expectativas. También resalta que negocio, desarrollo, testing, operaciones y usuarios aportan perspectivas distintas para calidad y riesgos.

En la BCU, el prompt de Importancia del conocimiento de los implicados pide como entrada: lista de implicados, tipo de conocimiento aportado, objetivos de calidad, metodología, riesgos y canales de comunicación; y como salida, tablas de conocimiento y plan de acciones. Eso es especialmente valioso para una reunión de arranque, porque te deja preparado no solo para escuchar, sino para preguntar, alinear y desafiar supuestos.

Finalmente, la BCU de RBT + Cuadrantes justifica combinar estructuración de pruebas con priorización por riesgo, participación whole-team y ajuste iterativo por sprint. Para un Sprint 0, esto te da una manera muy defendible de proponer qué probar primero y por qué.

5. Prompt completo listo para copiar

ROL

Actúa como un Test Manager senior certificado ISTQB, con experiencia en Sprint 0, análisis de anteproyectos, gestión de stakeholders, planificación temprana de pruebas, entornos ágiles e híbridos y Risk-Based Testing.

TAREA

Analiza el informe de anteproyecto que te proporcionaré para ayudarme a:

1. comprender el contexto real del producto y del proyecto,

2. identificar la información crítica que necesito como responsable de testing,

3. detectar vacíos, supuestos y riesgos,

4. preparar una posición sólida para participar activamente en la reunión de Sprint 0,

5. proponer una estrategia preliminar de testing para los primeros sprints.

CONTEXTO

Estoy a cargo de la gestión del testing del proyecto.

Tendremos una reunión de Sprint 0 con el equipo de proyecto para tratar los aspectos del producto que se desarrollará a lo largo de distintos sprints.

Necesito transformar el informe en decisiones, preguntas y prioridades de testing.

Quiero que apliques:

– Context priming

– Instructional scaffolding

– Verification & refinement loop

– Meta-prompting

– Role prompting

– Risk-Based Testing (RBT)

– Cuadrantes de prueba como apoyo de priorización, sin usarlos como checklist rígido

RAZONAMIENTO GUIADO

Sigue este proceso en orden:

Fase 1. Comprensión del contexto

– Resume el objetivo del producto, el alcance aparente, el modelo de trabajo sugerido y las restricciones visibles.

– Identifica si el contexto parece ágil, híbrido o ambiguo.

– Si el informe no lo aclara, decláralo como supuesto.

Fase 2. Análisis de implicados

– Identifica todos los implicados mencionados o inferibles: negocio, Product Owner, usuarios, desarrollo, arquitectura, QA, operaciones, seguridad, compliance, proveedores, soporte, etc.

– Para cada implicado, indica:

 – rol,

 – tipo de conocimiento que aporta,

 – impacto en la estrategia de pruebas,

 – nivel de influencia/interés,

 – riesgo si su información falta.

– Señala quiénes deben estar sí o sí involucrados en Sprint 0.

Fase 3. Detección de vacíos y preguntas críticas

– Detecta información faltante o ambigua del informe.

– Genera preguntas concretas que yo debería llevar a la reunión de Sprint 0.

– Prioriza las preguntas en alta, media y baja.

– Distingue preguntas de negocio, técnicas, de calidad/testing, de entorno/datos y de gobernanza.

Fase 4. Riesgos iniciales

– Identifica riesgos de producto y riesgos de proyecto.

– Evalúalos con probabilidad e impacto (alto/medio/bajo).

– Indica el efecto probable de cada riesgo sobre cobertura, calidad, calendario o dependencias.

– Relaciona los riesgos con implicados y con decisiones pendientes.

Fase 5. Estrategia preliminar de testing

– Propón un enfoque preliminar de pruebas para Sprint 0 y primeros sprints.

– Indica qué tipos de prueba parecen prioritarios.

– Propón una primera priorización usando RBT.

– Si es útil, mapea riesgos a cuadrantes de prueba Q1–Q4.

– Sugiere dependencias mínimas para arrancar: entornos, datos, herramientas, criterios de calidad, trazabilidad, automatización inicial, gestión de defectos, etc.

– Aclara qué decisiones aún no pueden cerrarse por falta de información.

Fase 6. Preparación para la reunión

– Indica exactamente cómo debería participar yo en la reunión:

 – qué validar,

 – qué cuestionar,

 – qué acordar,

 – qué dejar documentado.

– Redacta una lista de intervenciones recomendadas para un QA/Test Manager.

– Incluye alertas tempranas que convenga expresar diplomáticamente.

Fase 7. Validación y refinamiento

– Revisa si faltó algún implicado crítico, algún riesgo no funcional, alguna dependencia relevante o alguna decisión de testing importante.

– Corrige y optimiza la salida si detectas vacíos.

SALIDA ESPERADA

Entrega la respuesta con esta estructura exacta:

## A. Resumen ejecutivo del anteproyecto

## B. Clasificación del contexto (ágil, híbrido o ambiguo) y fundamentos

## C. Mapa de implicados

Tabla:

Implicado | Rol | Conocimiento aportado | Influencia/Interés | Impacto en testing | Riesgo si falta su input

## D. Vacíos del informe y preguntas para Sprint 0

Tabla:

Pregunta | Categoría | Prioridad | Por qué importa para testing | A quién dirigirla

## E. Riesgos iniciales

Tabla:

Riesgo | Tipo (producto/proyecto) | Probabilidad | Impacto | Prioridad | Mitigación de testing | Responsable sugerido

## F. Estrategia preliminar de testing

Tabla:

Decisión/Área | Propuesta inicial | Justificación | Dependencias | Estado (confirmar/definir/listo)

## G. Priorización RBT y cuadrantes

Tabla:

Riesgo | Cuadrante sugerido | Actividad de prueba | Momento recomendado | Responsable

## H. Guion de participación para la reunión

– 10 preguntas clave

– 5 decisiones que QA debería intentar cerrar

– 5 alertas tempranas que conviene dejar registradas

## I. Supuestos y límites del análisis

## J. Recomendación final como Test Manager

CONDICIONES

– No inventes información: separa claramente hechos, inferencias y supuestos.

– Si faltan datos, no bloquees el análisis: señala el vacío y formula la pregunta correcta.

– Prioriza claridad, accionabilidad y utilidad para Sprint 0.

– Evita respuestas genéricas.

– Considera riesgos funcionales y no funcionales.

– Si el contexto parece híbrido, explícita cómo afecta a la gestión del testing.

– Si el informe es pobre o incompleto, produce igualmente una preparación útil para la reunión.

PROMPT DE INPUT

A continuación pegaré el informe de anteproyecto:

[PEGAR AQUÍ EL INFORME]

PROMPT DE OUTPUT

Al finalizar, añade una sección extra:

“Evaluación de auditoría externa”

donde actúes como auditor ISTQB senior y respondas:

1. Qué lagunas críticas siguen abiertas.

2. Qué riesgo importante no está suficientemente tratado.

3. Qué debería corregir yo antes de entrar a Sprint 0.

4. Qué recomendación pondrías con prioridad alta, media y baja.

6. Riesgos y supuestos

Supongo que la reunión de Sprint 0 funcionará como una instancia de alineación inicial, no como una simple ceremonia administrativa. También supongo que el “informe de anteproyecto” todavía no contiene definición completa de estrategia, riesgos, entornos, datos ni decisiones cerradas de calidad; por eso te conviene usar el prompt para descubrir huecos, no solo para resumir contenido.

El principal riesgo de esta recomendación es que el proyecto no sea Scrum puro sino híbrido. En ese caso, la recomendación sigue siendo válida, pero necesitarás exigir más claridad en dependencias, aprobaciones, reporting y formalidad documental. Otro riesgo es que el informe tenga sesgo de negocio o técnico y omita inputs de operaciones, seguridad, compliance o usuarios; justamente por eso la capa de stakeholders y RBT es clave.

¿Necesitas apoyo en esta práctica? Contáctame por DM en LinkedIn

Gracias por seguirme.