Criterios de Aceptación

Los criterios de aceptación definen las condiciones que deben cumplirse para que una historia de usuario se considere completa. Transforman requisitos vagos en especificaciones comprobables, eliminando ambigüedad y previniendo la expansión del alcance.

Propósito

Los criterios de aceptación sirven múltiples roles:

Para desarrolladores: Requisitos claros antes de comenzar a codificar Para testers: Condiciones exactas a verificar Para stakeholders: Definición transparente de entregables Para product owners: Aplicación del límite del alcance

Sin criterios de aceptación, "hecho" se vuelve subjetivo. Con ellos, la completación es binaria—todos los criterios pasan o el trabajo continúa.

Acceder al Editor

Abre los criterios de aceptación desde los detalles de la historia de usuario:

1. Navega a cualquier historia de usuario
2. Haz clic en la pestaña Detalles
3. Encuentra la sección Criterios de Aceptación
4. Haz clic en el botón Editar (ícono de lápiz)

El editor se abre en un modal con opciones de formato de texto enriquecido.

Características del Editor

Barra de Herramientas de Formato

El editor de criterios de aceptación soporta:

Soporte de Texto Enriquecido

El editor preserva el formato al pegar desde:

• Google Docs
• Confluence
• Notion
• Microsoft Word

Pega contenido formateado directamente—la estructura se transfiere automáticamente.

Escribir Criterios Efectivos

El Formato Given-When-Then

Esta estructura crea condiciones inequívocas y comprobables:

Dado [precondición]
Cuando [acción]
Entonces [resultado esperado]

Ejemplo:

Dado que estoy logueado como administrador
Cuando hago clic en "Eliminar Usuario" y confirmo el diálogo
Entonces el usuario es eliminado del sistema
Y veo una notificación de éxito
Y el usuario ya no aparece en la lista de usuarios

Formato de Lista de Verificación

Para validaciones más simples, usa checkboxes:

- [ ] El formulario valida formato de email
- [ ] La contraseña requiere 8+ caracteres
- [ ] El botón Enviar está deshabilitado hasta que el formulario sea válido
- [ ] Los mensajes de error se muestran debajo de campos inválidos
- [ ] El éxito redirige al dashboard

Especificación por Ejemplo

Muestra el comportamiento esperado exacto:

Entrada: "juan@ejemplo.com"
Esperado: Válido, proceder al siguiente paso

Entrada: "juan@"
Esperado: Error "Formato de email inválido"

Entrada: ""
Esperado: Error "El email es requerido"

Categorías de Criterios

Criterios Funcionales

Lo que la característica debe hacer:

Dado un usuario con ítems en el carrito
Cuando hace clic en "Checkout"
Entonces ve el formulario de pago
Y el total del carrito se muestra correctamente
Y las opciones de envío se calculan

Criterios No Funcionales

Cómo la característica debe comportarse:

Rendimiento:
- La página carga en menos de 2 segundos
- La búsqueda retorna resultados en menos de 500ms
- Soporta 100 usuarios concurrentes

Accesibilidad:
- Todos los campos del formulario tienen etiquetas
- La navegación con Tab funciona correctamente
- Compatible con lectores de pantalla

Casos Límite

Condiciones de frontera y estados de error:

Casos límite manejados:
- Búsqueda vacía retorna mensaje de ayuda
- Timeout de red muestra opción de reintentar
- Expiración de sesión redirige a login
- Datos inválidos muestran errores específicos

Criterios de Seguridad

Requisitos de protección:

Requisitos de seguridad:
- Contraseñas hasheadas antes de almacenar
- Sesión expira después de 30 min de inactividad
- Intentos de login fallidos limitados a 5
- Datos sensibles no se registran en logs

Anti-Patrones a Evitar

Muy Vago

❌ Malo:

- Debe funcionar correctamente
- Debe ser rápido
- Necesita manejar errores

✅ Bueno:

- Retorna status 200 con entrada válida
- Responde en menos de 500ms bajo carga normal
- Muestra "Error de red, por favor reintente" en timeout

Muy Técnico

❌ Malo (a menos que el equipo sea todo desarrolladores):

- Usa Redis pub/sub para actualizaciones en tiempo real
- Implementa bloqueo optimista con ETag
- Despliega via rolling update de Kubernetes

✅ Bueno:

- Los cambios aparecen para todos los usuarios en 3 segundos
- Ediciones simultáneas muestran advertencia de conflicto
- El despliegue causa cero tiempo de inactividad

Probando la Implementación

❌ Malo:

- Usa hooks de React correctamente
- Las consultas de base de datos están optimizadas
- El código sigue la guía de estilo

✅ Bueno:

- El componente se re-renderiza solo cuando los datos cambian
- La lista carga en menos de 1 segundo para 10,000 ítems
- Consistente con patrones de UI existentes

Expansión del Alcance

❌ Malo (añade trabajo no incluido en la historia):

- También añadir soporte de modo oscuro
- Incluir exportación a PDF
- Añadir atajos de teclado

✅ Bueno (mantener el alcance de la historia):

- El dashboard muestra todos los widgets
- Los widgets cargan la configuración guardada del usuario
- El layout persiste entre sesiones

Integración con el Flujo de Trabajo

Durante la Planificación

1. Creación de historia: Redactar criterios iniciales
2. Refinamiento: El equipo discute, añade casos límite
3. Estimación: Los criterios informan la asignación de story points
4. Planificación del sprint: Los criterios verifican que la historia está lista

Durante el Desarrollo

1. Referencia: El desarrollador revisa criterios mientras codifica
2. Auto-prueba: El desarrollador verifica cada criterio antes del PR
3. Revisión de código: El revisor verifica cobertura de criterios

Durante el Testing

1. Creación de casos de prueba: Cada criterio se convierte en caso de prueba
2. Verificación: El tester valida todos los criterios
3. Reportes de bugs: Referencia criterios específicos que fallaron

Durante la Demo

1. Recorrido: Muestra cada criterio siendo cumplido
2. Aprobación: El stakeholder confirma aceptación

Atajos de Teclado

En el editor de criterios de aceptación:

Mejores Prácticas

1. Escribe Criterios Antes del Desarrollo

Los criterios escritos después de codificar tienden a coincidir con la implementación en lugar de los requisitos. Escribe primero, codifica después.

2. Involucra al Equipo

Los desarrolladores detectan vacíos técnicos. Los testers encuentran casos límite. Incluye ambas perspectivas al escribir criterios.

3. Mantén los Criterios Atómicos

Cada criterio prueba una cosa:

❌ Combinado:

El usuario puede iniciar sesión con credenciales correctas y ve el dashboard con sus datos

✅ Atómico:

- Credenciales válidas otorgan acceso
- Credenciales inválidas muestran error
- El dashboard se muestra después del login
- El dashboard muestra solo los datos del usuario

4. Usa Lenguaje Consistente

Establece convenciones del equipo:

• "Usuario" vs "Cliente" vs "Miembro"
• "Clic" vs "Seleccionar" vs "Elegir"
• "Mostrar" vs "Visualizar" vs "Renderizar"

5. Incluye Casos Negativos

Lo que NO debe pasar también importa:

- La contraseña nunca se muestra en logs
- Los datos eliminados no pueden recuperarse
- La sesión expirada no puede acceder a rutas protegidas

6. Versiona los Criterios

Cuando los requisitos cambian, actualiza los criterios y nota por qué:

Actualizado 2024-01-15: Añadido requisito de 2FA por auditoría de seguridad
Anterior: Login requiere email + contraseña
Actual: Login requiere email + contraseña + código 2FA

Plantillas Comunes

Operaciones CRUD

Crear:
- Entrada válida crea registro
- Entrada inválida muestra errores específicos
- Prevención de duplicados funciona

Leer:
- Usuarios autorizados ven datos
- Usuarios no autorizados ven error
- Estado vacío muestra mensaje de ayuda

Actualizar:
- Cambios se guardan correctamente
- Validación aplica a actualizaciones
- Manejo de edición concurrente funciona

Eliminar:
- Confirmación requerida
- Soft delete preserva datos
- Hard delete elimina completamente

Validación de Formulario

Campo: Email
- Requerido (muestra error cuando está vacío)
- Validación de formato (usuario@dominio.com)
- Longitud máxima: 254 caracteres
- Verificación de unicidad (muestra error si existe)

Campo: Contraseña
- Requerido
- Mínimo 8 caracteres
- Al menos un número
- Al menos un carácter especial
- Indicador de fortaleza se muestra

Endpoint de API

Endpoint: GET /api/users/{id}

Éxito (200):
- Retorna objeto de usuario
- Excluye campos sensibles (contraseña, tokens)
- Tiempo de respuesta < 200ms

No Encontrado (404):
- Retorna formato de error estándar
- Mensaje: "Usuario no encontrado"

No Autorizado (401):
- Token faltante retorna error
- Token expirado retorna error
- Token inválido retorna error

Solución de Problemas

El formato no se guarda:

• Revisa la consola del navegador para errores
• Intenta limpiar caché del navegador
• Asegura conexión de red estable

El editor no abre:

• Verifica permiso edituserstories
• Comprueba que la historia no esté archivada
• Actualiza la página y reintenta

El contenido pegado pierde formato:

• Intenta Pegar y Coincidir Estilo (Cmd/Ctrl + Shift + V)
• Usa formato Markdown para contenido complejo
• Divide en operaciones de pegado más pequeñas

Los cambios no son visibles para el equipo:

• Verifica que el guardado se completó (modal cerrado)
• Busca errores de sincronización en el feed de actividad
• Los miembros del equipo pueden necesitar actualizar

Crear Historia de Usuario

Las historias de usuario capturan requisitos desde la perspectiva del usuario final. Cada historia sigue el formato: "Como [quién], quiero [qué], para que [por qué]." Esta estructura asegura que cada característica tenga propósito claro y valor medible.

Abrir el Modal

Accede al modal de creación a través de múltiples caminos:

• Encabezado del proyecto: Haz clic en el botón "Nuevo" en la sección de historias de usuario
• Atajo de teclado: Cmd/Ctrl + Shift + U desde cualquier lugar en el proyecto
• Estado vacío: Haz clic en el enlace "Crea tu primera historia de usuario"
• Creación rápida: Usa el menú de creación rápida global y selecciona "Historia de Usuario"

El modal se abre con tu proyecto actual preseleccionado. Si lo abriste desde el menú global, selecciona primero el espacio de trabajo y proyecto.

Modos de Creación

Modo Tradicional

Escribe historias de usuario en el formato estándar:

Estructura de la plantilla:

Como [tipo de usuario],
Quiero [algún objetivo],
Para que [alguna razón].

Ejemplo:

Como gerente de proyecto,
Quiero ver gráficos de burndown del sprint,
Para que pueda rastrear la velocidad del equipo.

El formato tradicional asegura:

• Identificación clara de la persona usuaria
• Declaración de objetivo específica y accionable
• Justificación del valor de negocio

Escribir historias efectivas:

1. Sé específico sobre el usuario. "Como usuario" es muy vago. Usa "Como administrador de facturación" o "Como visitante por primera vez"

1. Enfócate en un objetivo. Si escribes "y" en la cláusula de quiero, considera dividir en múltiples historias

1. Declara valor medible. "Para que pueda ahorrar tiempo" es débil. "Para que pueda procesar 50% más facturas" es accionable

Modo IA

Describe lo que necesitas en lenguaje natural. La IA genera una historia de usuario correctamente formateada:

Entrada:

Necesito una forma para que los managers aprueben entradas de tiempo antes de que vayan a facturación

Historia generada:

Como gerente de equipo,
Quiero revisar y aprobar entradas de tiempo antes de exportar,
Para que mejore la precisión de facturación y disminuyan las disputas.

El modo IA sobresale cuando:

• Conviertes solicitudes de stakeholders en formato de historia de usuario
• Transformas reportes de bugs en historias de mejora
• Descompones requisitos vagos en necesidades específicas

Campos del Modal

Título (Requerido)

En modo Tradicional, este es tu texto completo de historia de usuario. En modo IA, esta es tu descripción en lenguaje natural.

Límite de caracteres: 500 caracteres Mejor práctica: Mantén los títulos escaneables. La primera línea debe resumir la historia.

Criterios de Aceptación

Define qué significa "hecho" para esta historia. Usa condiciones comprobables:

Criterios débiles:

- Debe funcionar correctamente
- Debe ser rápido
- Debe verse bien

Criterios fuertes:

- Las entradas de tiempo se muestran en orden cronológico
- El manager puede aprobar/rechazar entradas individuales
- Las entradas rechazadas regresan al remitente con comentario requerido
- Las entradas aprobadas se marcan con timestamp y nombre del aprobador
- La página carga en menos de 2 segundos para hasta 500 entradas

Opciones de formato:

Dado/Cuando/Entonces:

Dado que soy un manager logueado
Cuando veo las entradas de tiempo pendientes
Entonces veo las entradas agrupadas por miembro del equipo

Estilo de lista de verificación:

- [ ] Filtrar por rango de fechas funciona
- [ ] Aprobar masivamente entradas seleccionadas funciona
- [ ] Exportar entradas aprobadas a CSV funciona

Información Adicional

Contexto que ayuda durante la implementación:

• Enlaces a mockups de diseño
• Restricciones técnicas
• Documentación relacionada
• Contactos de stakeholders
• Casos límite a considerar

Este campo soporta formato Markdown completo incluyendo enlaces, bloques de código e imágenes.

Prioridad

Establece el nivel de urgencia de la lista de prioridades de tu proyecto:

La prioridad afecta:

• Ordenamiento predeterminado en vistas de backlog
• Sugerencias de planificación de sprint
• Cálculos de carga de trabajo del equipo

Épica

Vincula la historia a una épica padre para organización:

Sin Épica seleccionada: La historia aparece en el backlog sin agrupación Épica seleccionada: La historia se agrupa bajo la épica en vistas de roadmap y planificación

Crear Épica en línea: Haz clic en "Crear nueva épica" para añadir una épica sin salir del modal. Ingresa el título y guarda—la nueva épica es inmediatamente seleccionable.

Esto es valioso cuando:

• Una historia revela necesidad de una nueva iniciativa
• Un stakeholder solicita una característica fuera de épicas existentes
• Estás descomponiendo un requisito grande en épica + historias

Validación del Formulario

El botón crear se habilita cuando:

1. Proyecto seleccionado: Requerido para todas las historias
2. Título proporcionado: Mínimo 3 caracteres
3. Contenido apropiado al modo: Ya sea formato tradicional o descripción IA

Los errores de validación aparecen en línea:

• Título vacío: "El título es requerido"
• Título muy corto: "Mínimo 3 caracteres"
• Sin proyecto: "Selecciona un proyecto primero"

Después de la Creación

Estado de Éxito

El modal confirma la creación con opciones:

Ir a Historias de Usuario: Navegar al tablero de historias de usuario del proyecto Crear Otra: Limpiar formulario, permanecer en modal para creación por lotes

Qué Sucede

1. Historia creada con estado "Abierta"
2. Aparece en backlog lista para planificación de sprint
3. Vinculada a épica si se seleccionó
4. Equipo notificado via feed de actividad del proyecto
5. Sincronización en tiempo real en las vistas de todos los miembros del equipo

Atajos de Teclado

Mejores Prácticas

Escribe Independientemente

Cada historia debe ser completable sin dependencias:

Dependiente (evitar):

Como usuario, quiero ver el dashboard que fue creado en US-123

Independiente (preferido):

Como usuario, quiero ver métricas clave en mi dashboard

Dimensiona Apropiadamente

Las historias deben completarse dentro de un sprint. Si son más grandes:

• Divide en múltiples historias
• Usa épica para agrupar historias relacionadas
• Considera el patrón "Como usuario, quiero [parte 1]"

Incluye Criterios de Aceptación

Cada historia necesita condiciones comprobables. Esto no es opcional—es cómo tu equipo sabe cuándo el trabajo está completo.

Inversión de tiempo: 5 minutos escribiendo criterios ahorra 2 horas de preguntas de clarificación después.

Conecta con Épicas

Las historias huérfanas crean caos en la planificación. Incluso "mejoras misceláneas" merecen una épica para agrupar.

Patrones Comunes

Historia de Característica

Como [tipo de usuario],
Quiero [capacidad],
Para que [valor de negocio].

Conversión de Bug a Historia

Como [usuario afectado],
Quiero que [cosa rota] se arregle,
Para que [impacto cuando se arregle].

Historia Técnica

Como desarrollador,
Quiero [mejora técnica],
Para que [beneficio de mantenimiento/rendimiento].

Historia de Investigación

Como product manager,
Quiero entender [lo desconocido],
Para que [decisiones futuras].

Solución de Problemas

El modal no abre:

• Verifica permisos del proyecto (necesitas createuserstories)
• Asegura que el proyecto está seleccionado en la navegación
• Intenta actualizar la página

El modo IA no genera:

• Proporciona más detalle en la descripción
• Incluye contexto sobre tipo de usuario y objetivo
• Verifica conexión de red

No puedo seleccionar épica:

• Las épicas cargan después de la selección de proyecto
• Crea nueva épica si no existe ninguna
• Verifica que la épica no esté archivada

Desplegable de prioridad vacío:

• Las prioridades vienen de la configuración del proyecto
• El admin puede añadir prioridades en Configuración del Proyecto → Prioridades