Inception y preparación del primer sprint en Scrum
Contenido del curso
Juan Carlos Javier Vargas
Angela María García Tangarife
Profesor
Jorge Bernaola
Jorge Bernaola
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Alejandra Trujillo
Cornelio Reyes
Miguel Angel Cifuentes Sanchez
ORLANDO ERNESTO ARBAIZA AVILES
Diego Mauricio Zuluaga Rodríguez
Diego Mauricio Zuluaga Rodríguez
un par de preguntas: 1) La solución técnica es para cada historia de usuario? Mi duda es porque en el video se muestra antes del user story map, entonces cuando lleguen a las estimaciones volverán a definir el tipo de solución técnica.
2) Siendo que el Inception se desarrolle previamente a la planificación, qué tanto se debe desarrollar? según el video ya se desarrolló hasta las historias de usuario entonces ya no habría mucho que avanzar en el sprint planing.
Hola! Juan Carlos Respuesta 1: En esta clase de Inception, cuando se ejecuta este workshop o Taller de Inception, la solución técnica se define para todo el producto o servicio, no se diseña para cada una de las historias de usuario o para cada requisito. Defines todos los componentes técnicos que se van a requerir para construir la solución.
Respuesta 2: El taller de Inception no es una fase o actividad de desarrollo o construcción de producto o solución. El taller de Inception permite sentar las bases para iniciar con el primer sprint. Tiene como objetivo definir el alcance del producto, el impacto del producto para el negocio, quiénes serán parte del equipo scrum, qué riesgos se vislumbran y cual es la generalidad de las funcionalidades que tendrá el producto o servicio (User Story Map) y como técnicamente se construirá la solución. Es preparar el escenario para vivir el primer sprint. donde desa
MAPA DE INCEPTION ¿POR QUÉ?
Problema a resolver
¿QUIÉNES?
Usuarios y beneficiarios
¿CÓMO?
Enfoque y metodología
¿QUÉ?
Solución propuesta
MVP - Sprint 1 (2 semanas)
Funcionalidades esenciales para validar el producto con usuarios reales
🎯 Objetivo del MVP
Validar que los pacientes pueden agendar citas médicas digitalmente y acceder a su historial básico, reduciendo el ausentismo mediante recordatorios automáticos.
📊 Métricas de Éxito
Historias de Usuario MVP
US-001: Ver horarios disponibles
SP: 5
Como paciente, quiero ver horarios disponibles por especialidad y ubicación, para que pueda encontrar el momento ideal para mi consulta.
Criterios de aceptación: Filtros funcionales, carga bajo 2 segundos, disponibilidad en tiempo real
US-002: Agendar cita rápidamente
SP: 8
Como paciente, quiero reservar una cita en máximo 3 clics, para que el proceso sea rápido y no requiera llamadas telefónicas.
Criterios de aceptación: Máximo 3 pasos, confirmación instantánea, validación de disponibilidad
US-003: Acceder a historial médico
SP: 8
Como paciente, quiero ver mis últimas consultas y diagnósticos, para que pueda tener mi información médica siempre disponible.
Criterios de aceptación: Vista cronológica, datos completos, acceso seguro con autenticación
US-004: Descargar documentos médicos
SP: 5
Como paciente, quiero descargar mis recetas y resultados de exámenes, para que pueda compartirlos o imprimirlos cuando lo necesite.
Criterios de aceptación: Formato PDF, descarga inmediata, marca de agua institucional
US-005: Recordatorio automático
SP: 5
Como paciente, quiero recibir un recordatorio 24 horas antes de mi cita, para que no olvide mi consulta y pueda confirmar mi asistencia.
Criterios de aceptación: Email o SMS, 24h antes, enlace de confirmación, tasa de entrega 95%+
US-006: Confirmar asistencia
SP: 3
Como paciente, quiero confirmar mi asistencia con un solo clic, para que la clínica sepa que asistiré y no se pierda mi cita.
Criterios de aceptación: Botón directo en notificación, confirmación visual, actualización en sistema.
¿Qué es un inception y por qué antes del sprint?
Un Inception es un taller previo al primer sprint que alinea a equipo y stakeholders en torno a una iniciativa. Scrum no prescribe cómo hacerlo, pero adoptar esta práctica asegura que todos estén en la misma página antes de construir el producto. Puede durar de un día a un par de semanas según la complejidad.
¿Quiénes participan y cuánto dura?
Participan el equipo Scrum y las partes interesadas: usuarios, clientes, gerentes y expertos en el tema. La duración se ajusta a la complejidad: de un día a un par de semanas.
¿Qué entregables iniciales se obtienen?
¿Qué actividades clave aseguran el éxito?
El equipo de la aplicación de aprendizajes ejecutó actividades concretas: definir el objetivo, mapear la comunidad, construir el mapa de impacto, identificar riesgos, esbozar la solución técnica y crear el user story map.
¿Qué actividades clave aseguran el éxito?
El equipo de la aplicación de aprendizajes ejecutó actividades concretas: definir el objetivo, mapear la comunidad, construir el mapa de impacto, identificar riesgos, esbozar la solución técnica y crear el user story map.
¿Cómo definir objetivos smart con métricas?
El enfoque SMART pide que el objetivo sea específico, medible, con tiempo definido y orientado a resultados.
¿Cómo mapear la comunidad y actores?
Planear antes del primer sprint no solo es compatible con Scrum: es esencial para llegar al día de sprint planning con foco y acuerdos. Un Inception alinea al equipo y a las partes interesadas, define la visión del producto, aclara objetivos, riesgos y dependencias, y deja un product backlog inicial listo para empezar a generar valor.
Hola, pregunta, en este espacio de inception debería invitar a los gerentes cliente del producto, es decir no solo el equipo scrum sino todos los usuarios que pueden llegar a tener interes por la solucíón?
¡Totalmente! En el Inception participan no solo el equipo Scrum, sino también las partes interesadas clave: gerentes, clientes, usuarios referentes y expertos en el tema.
Eso sí, no necesitas a todos los usuarios del mundo en la sala, sino a los representantes o perfiles clave que aseguren una visión compartida y alineación real antes de arrancar. ¿Quiénes de esos actores clave tienes ya identificados para tu proyecto?
EL caso de Negocio es : SALUD TECH, pero se termina analizando y colocando como ejemplo una app para aprender ingles.... :( ? !
Si claro
Inception de Salud Tech
1. ¿Por qué estamos aquí? (Visión)
Nuestra meta: democratizar el acceso a la salud. Queremos que agendar una cita para una enfermedad crónica deje de ser un dolor de cabeza. No solo estamos haciendo una app, estamos haciendo más fácil la vida de pacientes y médicos.
2. ¿Quiénes somos? (El Equipo Scrum)
Para que esto funcione, necesitamos dejar atrás el trabajo aislado y la microgestión:
3. Nuestra "Gran Meta" (Product Goal)
En los próximos 3 meses, lograremos que los primeros 100 pacientes y 10 médicos gestionen sus citas de forma segura y sin fallos en nuestra plataforma.
4. ¿Qué vamos a atacar primero? (Prioridades MoSCoW)
Para no perdernos en funciones que no aportan hoy, nos enfocaremos en:
5. ¿Cómo sabemos que algo está bien hecho? (Definición de Terminado)
No basta con que "funcione en mi máquina". Para dar algo por terminado:
6. Nuestros Riesgos
En este Salud Tech, la transparencia es ley: si algo no sale o hay un impedimento, se habla en el momento, no semanas después.
Clase 25 – Inception: Preparación y Diseño
S. CASO SALUD TECH
Consideraciones clave para la sesión de Inception:
1. Facilitación y clima (humano primero)
- Andrea debe facilitar con un coach externo si es posible, dado el ambiente tenso. - Normas de convivencia: acuerdo explícito de “cero culpas, foco en soluciones” antes de empezar. - Check-in emocional: 10 min para que cada uno diga qué necesita del grupo para sentirse seguro de hablar.
2. Stakeholders críticos a mapear (30 min)
- Primarios: Pacientes crónicos, médicos de cabecera (2-3 entrevistados rápidos). - Secundarios: Administrador del hospital asociado (sistema de historias), inversionista potencial (Carlos trae feedback real). - Ancla: Carlos debe comprometerse a 4 horas de colaboración activa durante la Inception.
3. Riesgos y restricciones (40 min)
Convertir los riesgos identificados en acciones con owner y fecha:
- Deuda técnica: Rubén calcula el % de cobertura de tests actual en 30 min. - Baja autogestión: Todos votan qué decisión tomarían sin Carlos en 1 hora. - Ambigüedad de negocio: Carlos firma un “Contrato de Compromiso PO” (disponibilidad, priorización única). - Disponibilidad: Exponer el costo de oportunidad de cada reunión externa que cancela.
4. User Story Mapping colaborativo (2 horas)
- Todos los 5 miembros en una pared física o Miro. - Paso 1: Identificar Actividades principales (ej: “Agendar cita”), Tareas (ej: “Ver disponibilidad”), y Stories (ej: “Como paciente quiero ver horas disponibles…”). - Paso 2: Marcar con color rojo las dependencias técnicas entre Rubén, Laura y Antonio para romper silos.
5. Definición de MVP y Release 1 (1 hora)
- MVP = Solo 3 funcionalidades: (1) Registro/Login, (2) Ver disponibilidad, (3) Solicitar cita. - Release 1 = MVP + Cancelar cita + Confirmaciones. Formula y chat quedan FUERA. - Criterio de corte: ¿Qué demo podemos mostrar a 5 pacientes reales en 3 semanas?
6. Acuerdos de ingeniería (30 min) - Arquitectura: Decidir “API monolítica modular” en lugar de microservicios por simplicidad (votación técnica). - CI/CD: Configurar pipeline de integración continua antes del primer commit del Sprint 1 (owner: Laura). - Definición de Done: Incluye “ejecuta en el dispositivo de otro desarrollador sin errores”.
Output esperado: - One-pager de visión firmado por Carlos. - User Story Map con Release 1 y Sprint 1 marcados. - Lista de 5 acciones de mitigación de riesgo con dueño. - Plan de “Sprint 0” (2 días): setup de Git, CI y definir DoD.
---
T. PROYECTO PERSONAL – APP “FINZ”
Consideraciones clave para Inception en solitario:
1. Stakeholder minimalista - Yo: PO, SM y Dev. - Usuario beta: 1 amigo que invierta en bolsa (feedback semanal). - API externa: Alpha Vantage / Yahoo Finance (revisar límites de requests gratis).
2. Riesgo #1: Dependencia de API
- Acción: Crear capa de abstracción en 1 hora para poder cambiar de proveedor sin reescribir lógica. - Mitigación: Descargar dataset de prueba en CSV como “modo offline”.
3. MVP definido por frustración
- MVP = Solo 2 acciones: (1) Conectar broker y ver portfolio actual, (2) Recibir alerta si acción cae >5 %. - FUERA del MVP: Gráficos avanzados, chatbot de asesoría, meta de libertad financiera (fase 2). - Criterio de éxito: Yo mismo uso la app 5 días seguidos sin volver a Excel.
4. Restricciones personales
- Horas por semana: 8 horas (2 por día laborable). - Deadline real: Demo funcional en 1 mes para testear con usuario beta. - Tecnología: React Native (ya lo conozco) + Firebase (auth y DB sin backend propio).
5. Plan de Sprint 0 (4 horas)
- Hora 1: Crear repo Git, .env con API keys, script de hello-world de Alpha Vantage. - Hora 2: Sketch de 2 pantallas en papel (login, dashboard). - Hora 3: Defir DoD personal: “La feature corre en mi teléfono sin warnings y tiene test unitario”. - Hora 4: User Story Map de 3 columnas: “Ver plata → Decidir → Actuar”.
Output personal: - One-payer en Notion con visión y MVP. - 3 user stories en formato “Como inversor novato quiero…”. - Checklist de Sprint 0 visible en mi escritorio.
Está mal ubicado el quiz, debe ir después de que dictan el tema, no antes. Deben poner este quiz 39 segundos después.
