Ejemplo de cronograma de sprint
El cronograma mantiene al comprador centrado en pruebas semanales, no en un teatro de transformación a gran escala.
Ritmo habitual
El descubrimiento fija primero el alcance. La primera semana valida la ruta de datos. La segunda hace usable el flujo de trabajo. Las semanas siguientes se dedican a reforzar el sistema e integrarlo.
- Días 0-2: cierre del alcance
- Semana 1: prototipo
- Semana 2: piloto usable
- Semanas 3-6: preparación para producción y despliegue
Por qué se escribe el cronograma
El cronograma no es una promesa de que todas las ideas tarden los mismos días. Es una herramienta de control que mantiene visibles las pruebas, los riesgos, las demos y las siguientes decisiones.
- Cierre del alcance antes de construir
- Validación temprana de datos/APIs
- Ritmo de demos semanales
- Refuerzo solo después de la prueba
- Decisión al final
Qué cambia según el tipo de sprint
Un sprint de automatización de documentos dedica más tiempo a muestras y colas de revisión. Un sprint de API dedica más tiempo a contratos y comportamiento ante fallos. Un flujo de trabajo con LLM dedica más tiempo a evaluación y salvaguardas.
- Automatización de documentos: muestras y revisión
- Sprint de API: contratos y errores
- Flujo de trabajo con LLM: evaluación y respaldo
- Sprint de app: UX y recorrido del usuario
Preguntas frecuentes
- ¿Todos los sprints duran 2 semanas?
- No. Dos semanas funcionan bien para una primera prueba. Algunos alcances necesitan 3-6 semanas cuando hay integración de APIs, seguridad o varios roles de usuario.
- ¿Qué debe pasar antes de la primera semana?
- El alcance, el acceso a datos, los usuarios, el responsable de la decisión y los criterios de aceptación deben estar lo bastante claros para empezar.
- ¿Cuándo conviene empezar a reforzar el sistema?
- Después de probar la ruta principal. Reforzar demasiado pronto puede acabar puliendo el flujo de trabajo equivocado.