Criterios de aceptación vs definición de terminado en Scrum
Contenido del curso
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
Ixcoatl Francisco Pérez
José David Calderón Serrano
Condor Agency
ORLANDO ERNESTO ARBAIZA AVILES
Diego Mauricio Zuluaga Rodríguez
¿Cómo redactar y validar criterios de aceptación en historias de usuario?
Para una app de aprendizaje de idiomas, se plantea listar verbos para que la persona usuaria aprenda significado y pronunciación. Ejemplos de criterios de aceptación que ilustran claridad y comprobabilidad:
Estos criterios orientan el desarrollo y la prueba funcional. Al ser medibles, facilitan la validación por parte del equipo y de las partes interesadas. Además, sirven para diseñar casos de prueba claros y evitar interpretaciones distintas dentro del equipo.
¿Qué diferencia a criterios de aceptación y definición de terminado?
Los criterios de aceptación son condiciones específicas que permiten verificar si una historia está completamente lista y desarrollada. Son únicos por historia: describen qué se espera exactamente del comportamiento o resultado.
La definición de terminado (Definition of Done) es un criterio de calidad transversal a todo el incremento. Actúa como un estándar formal: si una historia no lo cumple, no puede presentarse en el sprint review. Este enfoque fomenta disciplina técnica y consistencia.
Habilidades clave que se ejercitan: refinamiento del backlog para aclarar alcance, estimación para dimensionar esfuerzo y verificación sistemática contra criterios. Todo con foco en calidad y valor del producto.
Estos criterios orientan el desarrollo y la prueba funcional. Al ser medibles, facilitan la validación por parte del equipo y de las partes interesadas. Además, sirven para diseñar casos de prueba claros y evitar interpretaciones distintas dentro del equipo.
¿Qué incluye una buena definición de terminado para el sprint review?
La definición de terminado eleva el estándar técnico y de producto, garantizando que cada historia se integre con calidad al incremento. Componentes típicos que deben cumplirse para todas las historias:
Dado el caso de negocio Salud Tech:
i.Define los criterios de aceptación para las 3 historias de usuario previamente creadas en la clase anterior.
Identifica de 3 a 5 criterios de aceptación por cada historia de usuario
Historia 1: Registro e Inicio de Sesión Seguro
# Criterio de Aceptación Tipo Verificación
1 El usuario recibe un correo de verificación dentro de los 60 segundos posteriores al registro completo Funcional Test automatizado de tiempo de envío
2 El sistema rechaza correos electrónicos inválidos o ya registrados con mensaje claro de error Seguridad UX Prueba de edge cases con correos duplicados
3 La autenticación de dos factores (2FA) se activa obligatoriamente para roles de médicos Seguridad Escaneo de configuración de seguridad
4 Las contraseñas se almacenan solo como hash (no texto plano) usando algoritmo bcrypt ≥12 rounds Consistencia Datos/Auditoría Revisión de código backend
5 Tras 3 intentos fallidos, la cuenta se bloquea temporalmente por 15 minutos (protección fuerza bruta) Seguridad Simulación de ataques en testing
Historia 2: Configuración de Disponibilidad Horaria (Médico)
# Criterio de Aceptación Tipo Verificación
6 El médico puede configurar bloques horarios mínimos de 15 minutos hasta máximos de 4 horas continuas Funcional Validación UI + backend
7 Cuando un paciente reserva, el espacio disponible desaparece inmediatamente en el calendario público (sincronización ≤1 segundo) Consistencia Datos Testing de concurrencia simulada
8 El médico puede cancelar disponibilidad previa con notificación automática a pacientes citados con 24h mínimo de anticipación Legal/UX Flujo completo de cancelación
9 Los cambios de disponibilidad se registran en log con timestamp, ID de usuario y acción realizada (auditoría) Seguridad/Auditoría Revisión de logs en staging
10 No es posible establecer citas en días festivos predefinidos por la institución médica Regla de Negocio Prueba con calendario institucional
Historia 3: Solicitar y Agendar Nueva Cita (Paciente)
# Criterio de Aceptación Tipo Verificación
11 El paciente puede buscar citas filtrando por especialidad, ubicación y ventana máxima de 7 días Funcional Buscador con múltiples filtros activos
12 Al confirmar cita, el paciente recibe confirmación inmediata por email Y SMS (ambos canales) Usabilidad/Valor Prueba en ambiente con senders configurados
13 El sistema impide doble reserva (mismo horario, mismo médico) mediante validación transaccional atómica Consistencia Datos Test de concurrencia de reservas simultáneas
14 El paciente puede cancelar sin penalización hasta 24 horas antes de la cita programada Política Servicio Flujo de cancelación funcional
15 Toda transacción de cita genera un ID único y trazable para auditoría y reclamos del paciente Seguridad/Compliance Verificación de base de datos de citas
ii.¿Cuál sería la Definición de Terminado inicial para el equipo Salud Tech?
La DoD es la checklist de calidad que todas las historias deben cumplir para considerarse "Terminadas". Para equipos de salud tech, los estándares son altos por regulaciones:
Fase Criterio de DoD Responsable
Desarrollo Código escrito siguiendo estándares de codificación del equipo Developer
Revisión Pull Request aprobado por al menos 1 desarrollador senior Reviewer
Testing Tests unitarios con cobertura mínima del 80% en funcionalidades críticas QA/Developer
Integración Build pasa sin errores en pipeline CI/CD DevOps
Seguridad Escaneo SAST/DAST limpio (sin vulnerabilidades High/Critical) Security
Datos Migraciones de BD probadas en ambiente staging primero Developer
Documentación API documentada en Swagger/OpenAPI si corresponde Developer
Accesibilidad Cumple WCAG 2.1 AA (crítico para sector salud inclusivo) UX/QA
Cumplimiento Revisión legal/privacidad aprobada para manejo de datos sensibles Compliance
Deploy Desplegado exitosamente en ambiente de producción DevOps
Dado tu Proyecto personal:
i.Haz lo mismo para tu proyecto personal
i. Criterios de Aceptación Detallados (3-5 por Historia)
Historia 1: La Narrativa Inmersiva (Lore System)
# Criterio de Aceptación Tipo Verificación
1 El sistema muestra fragmentos narrativos de <15 segundos durante cargas de nivel Funcional Medición de tiempo de exposición
2 La narrativa avanza secuencialmente solo tras completar objetivos del juego (sin saltos arbitrarios) Consistencia Datos Log de progreso de jugador
3 El progreso de lore se guarda en cloud y se sincroniza entre dispositivos en ≤5 segundos Consistencia Datos Sync test entre móvil/tablet
4 Cuenta de usuario autenticada segura (token JWT expirable cada 24h) para proteger progreso Seguridad Penetration testing básico
5 El contenido narrativo no contiene referencias protegidas por copyright sin licencia Legal/IP Revisión manual de assets
Historia 2: Identidad Visual Rápida (Personajes/Sprites)
# Criterio de Aceptación Tipo Verificación
6 Sprites diferenciables visualmente en resolución mínima de 720p (paleta de colores única por jugador) Usabilidad Prueba con monitores estándar
7 Sistema de elección de skin se guarda asociado al usuario (persistencia de preferencias) Consistencia Datos DB audit de preferencias guardadas
8 Assets de sprites pasan validación antivirus antes de ser descargados al cliente Seguridad Escaneo en pipeline de build
9 Tamaño de archivo de sprite por personaje ≤10KB para carga rápida en móviles Rendimiento Auditoría de assets
10 Animaciones básicas (camina, salta, ataca) funcionan correctamente en todos los skins disponibles Calidad Juego QA manual + auto-test
Historia 3: Exploración Ágil de Mundos (Mapas/Niveles)
# Criterio de Aceptación Tipo Verificación
11 Tiempo de carga total del nivel ≤3 segundos en dispositivo móvil gama media Rendimiento/Valor Benchmark en Android/iOS real
12 Posiciones de jugadores sincronizadas con latencia ≤100ms entre participantes Consistencia Datos Test de red simulada
13 Autenticación de sesión requerida para acceso a servidores multijugador Seguridad Intento de acceso sin login bloqueado
14 Cada nivel tiene objetivo principal identificable en ≤30 segundos de gameplay Usabilidad/Valor Playtest con usuarios beta
15 Anti-cheat básico previene manipulación de posición/habilidad visible en servidor Seguridad Scan de memoria client-side
ii. Definición de Terminado (DoD) - Equipo Proyecto Personal
Para un proyecto personal/grupal universitario, la DoD puede ser más práctica pero igual rigorosa:
Fase Criterio de DoD Responsable
Gameplay Mecánica funciona en flujo completo sin bloqueos ni bugs crasheantes Developer/Programmer
Gráficos Todos los assets visibles se renderizan correctamente en pantalla objetivo Artist/Dev
Audio Música y efectos de sonido activan/desactivan según contexto de juego Designer
Testing Pasó prueba de "jugabilidad" con al menos 3 personas fuera del equipo QA/Todos
Rendimiento FPS estable ≥30 en dispositivos objetivo (móvil/computadora) Developer
Red Multijugador estable en conexión WiFi doméstica promedio Network Dev
Contenido Story/Lore entregado en formato editable (no hardcodeado) Designer/Writer
Deploy Build ejecutable empaquetado listo para distribución Developer
Backup Repositorio Git actualizado con versionado semántico Todos
Documentación README con instrucciones de instalación y controladores básicos Todos
Definition of Done para el caso de estudio Salud Tech:
-Código debe ser revisado por otros desarrolladores
-Se debe cumplir con los requerimientos HIPPA
-El código debe cumplir todas las pruebas de calidad unitarias y pruebas de regresión automáticas (Test Automation y Clean Code)
-Cumplir con requerimientos generales de seguridad
-El código no debe tener defectos conocidos
-Código debe estar documentado adecuadamente
A diferencia de los criterios de aceptación que son por historia de usuario, la definición de terminado es un estándar que se aplica a todas las historias de usuario y entiendo que a todos los elementos del backlog para que el incremento tenga valor.
Clase 19 – Criterios de Aceptación y Definición de Terminado (DoD)
---
k. CASO SALUD TECH
i. Criterios de Aceptación por Historia de Usuario
Historia 1: Agendar Cita Rápida
Como paciente crónico frustrado, quiero solicitar y confirmar una cita médica en menos de 2 minutos, para dejar de esperar semanas por teléfono y sentir que tengo control sobre mi salud.
Criterios de Aceptación (5):
1. Velocidad: El flujo completo (seleccionar médico → elegir fecha/hora → confirmar) se completa en máximo 8 clics y 90 segundos en conexión 3G.
2. Consistencia: El sistema bloquea el horario seleccionado por 120 segundos con bloqueo optimista PESSIMISTIC_LOCK; si expira, libera automáticamente el slot.
3. Notificación: Paciente y médico reciben push + email con QR de la cita en ≤10 segundos. El email tiene asunto "Cita Confirmada - Dr. [Nombre] - [Fecha]" y cuerpo con dirección, hora y teléfono.
4. Validación: Si el slot se ocupa mientras el paciente confirma, se muestra mensaje "Este horario fue tomado" con 3 alternativas recomendadas sin regresar al inicio.
5. Seguridad: Endpoint POST /appointments loguea en tabla audit_appointments (user_id, timestamp, IP, action) y valida JWT con rol "PATIENT". Intentos sin token devuelven 401 Unauthorized.
---
Historia 2: Publicar Disponibilidad Médica
Como médico principal, quiero configurar mis horarios de atención semanal de forma flexible, para garantizar que los pacientes vean solo espacios reales y evitar el riesgo de sobrecarga o huecos vacíos.
Criterios de Aceptación (5):
1. UX: Interfaz drag-and-drop permite crear bloques de 30 min arrastrando en calendario; al soltar, el bloque se guarda automáticamente sin botón "Guardar".
2. Validación de conflictos: Al publicar, el sistema ejecuta query que detecta solapamientos con citas existentes. Si encuentra ≥1, muestra lista de citas afectadas y pide confirmación "¿Mover estas citas?".
3. Tiempo de propagación: Cambios reflejados en la vista de pacientes en ≤60 segundos mediante cache invalidation en Redis.
4. Histórico: Todo cambio queda registrado en tabla doctor_schedule_history (doctor_id, old_slot, new_slot, changed_at) para auditoría interna.
5. Seguridad: Requiere 2FA via Google Authenticator para guardar cambios. Endpoint PUT /schedule verifica TOTP code; sin él, devuelve 403 Forbidden.
---
Historia 3: Cancelar Cita sin Fricción
Como paciente con una agenda impredecible, quiero cancelar mi cita con un clic y que el espacio se libere al instante, para liberar el horario para otro paciente que lo necesite urgente y evitar ser sancionado por "no-show".
Criterios de Aceptación (4):
1. Un clic: Botón "Cancelar" en detalle de cita → modal de confirmación con motivo (opcional) → al confirmar, la cita desaparece del calendario del paciente inmediatamente.
2. Liberación instantánea: Slot vuelve a estado "available" en calendario del médico en ≤5 segundos y es visible para otros pacientes sin refrescar.
3. Notificación: Médico recibe push "Cita cancelada - [Paciente] - [Hora]" con 3 botones: "Ver agenda", "Re-agendar", "Ignorar".
4. Seguridad: Solo el paciente dueño (JWT sub == patient_id de la cita) o rol ADMIN pueden cancelar. Endpoint DELETE /appointments/{id} valida ownership; intento de cancelación ajena loguea incidente de seguridad.
---
ii. Definición de Terminado (DoD) Inicial – Equipo Salud Tech
Checklist obligatorio antes de pasar a "Done": - ✅ Código: Commiteado en rama feature/XXX con mensaje claro; merge a develop solo vía pull request. - ✅ Revisiones: Code review aprobado por otro desarrollador (Rubén, Laura o Antonio). No puede aprobarse solo. - ✅ Pruebas: Cobertura mínima 70% en funcionalidades nuevas (unitarios con Jest/JUnit). Prueba de integración del endpoint en ambiente de staging. - ✅ CI/CD: Pipeline de GitHub Actions ejecuta sin errores: build + tests + link. Build debe ser <5 min. - ✅ Documentación: Swagger actualizado para endpoints nuevos; README con ejemplo de request/response. - ✅ Seguridad: Escaneo Snyk/GitGuardian no detecta secrets en código; análisis estático SonarQube pasa sin vulnerabilidades críticas. - ✅ Aceptación: Funcionalidad demoable en dispositivo físico de otro miembro del equipo (no simulador). - ✅ PO Approval: Carlos valida en entorno staging que cumple los criterios de aceptación y firma virtual.
---
l. PROYECTO PERSONAL – APP "FINZ"
i. Criterios de Aceptación por Historia de Usuario
Historia 1: Conectar Broker
Como inversor novato, quiero conectar mi cuenta de broker ingresando solo una API key, para ver mi portfolio actualizado automáticamente sin tener que transcribir manualmente cada operación.
Criterios de Aceptación (3):
1. Validación: Al ingresar API key, la app llama a endpoint /v2/account de Alpaca (o Proveedor X) y muestra "Conectado" + nombre de cuenta en <5s. Si falla, muestra error específico: "Key inválida o permisos insuficientes". 2. Persistencia: Key se guarda en Keychain (iOS) / Keystore (Android) encriptada AES-256; nunca se muestra en pantalla completa ni se guarda en texto plano. 3. Sincronización: Portfolio se actualiza al abrir la app y manualmente al hacer pull-to-refresh; muestra última actualización con timestamp. 4. Offline: Si no hay conexión, muestra últimos datos cacheados con banner "Datos desactualizados - Modo Offline".
---
Historia 2: Alerta de Caída
Como inversor con trabajo de tiempo completo, quiero recibir una alerta si cualquier acción de mi portfolio cae más del 5% en un día, para decidir si detener pérdidas sin estar todo el día mirando la pantalla.
Criterios de Aceptación (4):
1. Configuración: Toggle "Alertas activas" en settings; al activar, pide confirmación "¿Permitir notificaciones push?" si no están habilitadas a nivel OS. 2. Trigger: App ejecuta job cada 5 min en background; calcula cambio % desde precio de cierre anterior. Si ≤ -5%, envía notificación push con sonido y badge. 3. Contenido: Notificación dice "⚠️ AAPL -5.2% - Ver ahora?" y al tocarla abre detalle del activo con gráfico intradía. 4. Rate limit: Máximo 1 notificación por activo cada 24h; si vuelve a caer, no se repite hasta el día siguiente. 5. Silencio: Horario "No molestar" 22:00-07:00; alertas fuera de ese rango se acumulan y se envían a las 07:01.
---
Historia 3: Proyección a Meta
Como persona con meta de libertad financiera, quiero ver una proyección realista de cuántos meses me falta alcanzar mi meta basado en mi rendimiento actual, para motivarme a mantener la disciplina de ahorro.
Criterios de Aceptación (3):
1. Input: Pantalla "Mi Meta" con dos campos: (1) Monto objetivo (USD) y (2) Ahorro mensual (USD). Botón "Calcular".
2. Cálculo: Usa tasa de retorno anualizada del portfolio (time-weighted return) de últimos 3 meses. Fórmula: meta = ahoro \* \[(1+r)^n - 1]/r. Muestra resultado "Faltan 14 meses (estimado: Mayo 2026)".
3. Visualización: Barra de progreso con % actual vs meta; color verde si proyección <24 meses, amarillo si 24-60 meses, rojo si >60 meses.
4. Testable: Al cambiar meta de 100k a 200k, la proyección se actualiza en tiempo real sin guardar ni refrescar.
---
ii. Definición de Terminado (DoD) Personal – Proyecto FinZ
Checklist individual antes de marcar "Done":
- ✅ Funciona en mi teléfono: La feature se ejecuta en dispositivo físico sin crashes ni warnings amarillos en Metro bundler.
- ✅ Test unitario: Al menos 1 test con Jest que cubra la lógica principal de la historia (ej: cálculo de proyección).
- ✅ Sin hardcoded: API keys y magic numbers en .env o archivo de configuración, nunca en código fuente.
- ✅ Offline tolerante: Si pierdo conexión, la app no se rompe; muestra mensaje claro y datos cacheados.
- ✅ Commit semántico: Mensaje tipo feat: HU3 proyección meta con cálculo compuesto (convencional commits).
- ✅ Demo ready: Puedo grabar un video de 30 segundos mostrando la funcionalidad para compartir con usuario beta.
- ✅ Documentado: Nota en Notion explicando qué hace, cómo testearlo y qué decisiones técnicas tomé.
