Cómo redactar criterios de aceptación que mejoren la claridad del proyecto
Ryan Tanner
Especialista en Marketing de Producto
21 sep 2026
Ryan Tanner
21 sep 2026
16 min
Saber escribir criterios de aceptación es esencial para garantizar que los gerentes de producto, desarrolladores y control de calidad comprendan realmente lo que significa “terminado”. Criterios de aceptación sólidos reducen la ambigüedad, guían las decisiones de desarrollo y aseguran que las funciones cumplan con las expectativas reales de los usuarios. Actúan como una definición compartida de éxito, ayudando a los equipos a evitar malentendidos y retrabajos innecesarios.
En esta guía, aprenderás a redactar criterios de aceptación efectivos, explorarás formatos clave como Dado–Cuando–Entonces y revisarás ejemplos de declaraciones buenas y malas. A medida que los proyectos escalan, gestionar este proceso en varios equipos puede volverse complejo, y es ahí donde plataformas conectadas como Lark ayudan a los equipos a colaborar, revisar y dar seguimiento a los criterios de aceptación sin el caos de versiones de las herramientas tradicionales.
¿Qué son los criterios de aceptación?
Los criterios de aceptación son condiciones específicas y medibles que una historia de usuario o una función deben cumplir para que se consideren completas. Definen cómo debe comportarse el producto desde la perspectiva del usuario y establecen los límites de la funcionalidad que se entrega. Cuando los equipos comprenden cómo redactar criterios de aceptación de manera clara, reducen la ambigüedad, evitan interpretaciones erróneas y aseguran que el desarrollo se alinee con las necesidades reales del usuario. Los criterios de aceptación también forman la base para las pruebas de control de calidad, lo que facilita validar los resultados de manera objetiva.
Aprender a redactar historias de usuario y criterios de aceptación en conjunto garantiza que tanto el contexto (el objetivo del usuario) como las expectativas (el resultado requerido) se comprendan bien. Los equipos que se enfocan en redactar buenos criterios de aceptación suelen utilizar formatos como listas de verificación o el esquema Dado–Cuando–Entonces para asegurar que cada enunciado sea comprobable. Esta práctica fortalece la alineación entre gerentes de producto, desarrolladores y control de calidad, ayudando a que los proyectos se desarrollen con mayor fluidez y mejorando la calidad de los entregables.
Formatos comunes de criterios de aceptación
Diferentes equipos utilizan distintos formatos de criterios de aceptación según su flujo de trabajo, el nivel de detalle técnico y las necesidades de colaboración. Elegir la estructura adecuada ayuda a garantizar claridad y coherencia en todos los requisitos. Algunos formatos están más basados en escenarios, mientras que otros son listas de verificación simples o se enfocan en reglas para entornos empresariales estrictos. Comprender cuándo usar cada formato ayuda a los equipos a redactar criterios de aceptación que sean comprobables, accionables y fáciles de validar.
Formato Dado–Cuando–Entonces (estilo BDD):
- Este formato modela el comportamiento como escenarios, describiendo un estado inicial, un desencadenante y el resultado esperado. Es especialmente eficaz en equipos ágiles que practican desarrollo guiado por comportamiento o pruebas automatizadas. Úsalo cuando los flujos de usuario, la lógica de decisiones o las interacciones del sistema necesiten ser explícitos.
- Ejemplo:
- Dado que el usuario ha iniciado sesión
- Cuando haga clic en "Descargar factura"
- Entonces la factura debería descargarse como un PDF.
Lista de verificación o formato de viñetas:
- Este formato enumera las condiciones que deben cumplirse antes de que la función se considere completa. Es simple, legible y funciona bien para equipos multifuncionales que revisan la funcionalidad juntos. Úsalo cuando la claridad y la revisión rápida sean más importantes que el modelado detallado de escenarios.
- Ejemplo:
- Botón "Agregar al carrito" visible en todas las páginas de productos.
- Los artículos agotados muestran la opción "Avísame".
Formato orientado a reglas:
- Esta estructura define reglas del sistema o restricciones comerciales que siempre deben cumplirse. Es más útil en entornos regulados, con alta carga lógica o impulsados por políticas. Utilice este formato cuando sea necesario aplicar reglas de precios, criterios de elegibilidad, umbrales o condiciones de cumplimiento.
- Ejemplo:
- El descuento aplica únicamente a pedidos superiores a $100.
Guía paso a paso para redactar criterios de aceptación efectivos
Redactar criterios de aceptación no se trata solo de documentar requisitos, sino de crear un entendimiento compartido del resultado deseado. El objetivo es dejar las expectativas lo suficientemente claras para que cualquier miembro del equipo pueda revisar los criterios y determinar con confianza si el trabajo está completo. Los criterios bien redactados son específicos, medibles y validados de forma colaborativa antes de que comience el desarrollo. Seguir un enfoque estructurado garantiza que los criterios se mantengan consistentes y alineados con las necesidades del usuario.
Paso 1: Comprender claramente la historia de usuario
Comienza revisando el propósito de la historia de usuario y el valor que busca ofrecer. Asegúrate de comprender claramente quién es el usuario y qué intenta lograr. Una historia de usuario bien interpretada constituye la base de criterios de aceptación sólidos.
Paso 2: Alinear con las partes interesadas
Involucra a gerentes de producto, diseñadores, desarrolladores y QA desde el inicio de la conversación. Aclarar las expectativas desde el principio reduce la confusión y los desacuerdos más adelante. La alineación garantiza que todos compartan el mismo entendimiento del resultado final.
Paso 3: Usa un lenguaje y una estructura consistentes
Escribe los criterios en un formato predecible para que sean más fáciles de revisar y probar. Mantén cada criterio enfocado en un solo resultado para conservar la claridad. La consistencia garantiza que los criterios se comprendan de la misma manera por todos.
Paso 4: Evita la jerga técnica
Los criterios de aceptación deben describir lo que el usuario experimenta, no cómo se implementa el sistema. Los detalles técnicos pertenecen a la documentación de diseño o ingeniería. Usar un lenguaje sencillo asegura claridad entre funciones.
Paso 5: Manténlos medibles
Incluye valores específicos, umbrales o mensajes esperados para que el éxito sea fácil de verificar. Los criterios medibles evitan interpretaciones subjetivas como “rápido” o “fácil de usar”. Esto asegura que el resultado pueda probarse objetivamente.
Paso 6: Valida de forma colaborativa
Revisen juntos los criterios de aceptación durante la refinación del backlog o la planificación del sprint. Inviten preguntas y ajusten la redacción para eliminar ambigüedades. La validación colaborativa asegura que todos los interesados estén de acuerdo antes de que comience el desarrollo.
Ejemplos de criterios de aceptación buenos vs malos
Mal escrito | Bien escrito |
El sistema debería cargar rápido. | "El panel de control carga en menos de 3 segundos con banda ancha." |
El usuario puede enviar el formulario. | "Cuando el formulario es válido, al hacer clic en Enviar se muestra un mensaje de éxito y se guardan los datos." |
Las notificaciones deberían funcionar. | El usuario recibe un correo electrónico y una alerta en la aplicación dentro de 1 minuto después de la aprobación. |
La búsqueda debería funcionar correctamente. | "Cuando un usuario busca por palabra clave, los resultados que coinciden con el título o la descripción aparecen en un plazo de 2 segundos." |
El perfil de usuario debería actualizarse. | "Cuando el usuario edita los detalles del perfil y hace clic en Guardar, los cambios se reflejan de inmediato en su panel." |
"Los reportes deben generarse rápidamente." | "Descargas del informe mensual en formato PDF dentro de los 5 segundos posteriores a seleccionar un rango de fechas." |
Si bien las hojas de Excel y las herramientas tradicionales ayudan a documentar los criterios de aceptación, pueden llenarse de desorden rápidamente a medida que los equipos crecen. La confusión de versiones, los comentarios dispersos y las revisiones lentas hacen que la colaboración sea más difícil de lo que debería. Ahí es donde entra en juego un espacio de trabajo conectado como Lark, que reúne la documentación, la comunicación y la ejecución en un solo lugar, para que cada criterio de aceptación se mantenga claro, actualizado y procesable.
Hora de actuar: Usa Lark para gestionar, revisar y dar seguimiento a los criterios de aceptación
Gestionar los criterios de aceptación en múltiples historias, sprints y equipos puede volverse complejo rápidamente, especialmente cuando las discusiones ocurren en herramientas desconectadas. La confusión de versiones, los comentarios dispersos y la falta de claridad en la responsabilidad suelen provocar desalineación y retrabajo. Lark resuelve esto al reunir la documentación, la comunicación, las tareas y los datos en un solo espacio de trabajo conectado. Los equipos pueden revisar, perfeccionar y aprobar juntos los criterios de aceptación, sin perder el contexto ni perseguir actualizaciones a través de diferentes canales.
Base de Lark: Fuente única de verdad para historias y criterios de aceptación
Usa Lark Base para modelar historias de usuario, criterios de aceptación y preparación en tablas vinculadas. Campos típicos: ID de historia, épica, prioridad, sprint, responsable, ID de AC, formato (dado–cuando–entonces / lista de verificación), ¿testeable? (S/N) y estado (borrador/listo/aprobado). El equipo de producto añade criterios a cada historia; QA marca “testeable” una vez que la redacción es objetiva y medible. Las vistas por sprint o equipo muestran al instante qué historias están “listas para desarrollo” frente a “necesitan aclaración”. Con un flujo de trabajo automatizado, Base puede asignar automáticamente un revisor cuando un criterio cambia y avisar a los responsables si “listo para QA” permanece sin avance durante 24 horas.
Lark Messenger: Mantén las conversaciones vinculadas al trabajo
Con Lark Messenger, puedes compartir registros individuales de Base (como historias o criterios de aceptación) como tarjetas de vista previa o enlaces en los chats de Lark Messenger, lo que permite a los destinatarios verlos o editarlos directamente. Con pines, banderas, respuestas en hilos y uso compartido de archivos, Lark Messenger mantiene las conversaciones completamente en contexto. Todo el contexto y el historial conservado se almacenan para auditorías y retrospectivas.
Tareas de Lark: convertir los criterios aprobados en trabajo accionable
Una vez que se aprueben los criterios, asígnalos en Lark Tasks, con responsables, fechas de entrega y casillas de verificación de aceptación que reflejen la lista de AC. Las tareas se pueden sincronizar desde documentos, y los responsables pueden ver sus tareas incluso sin acceso al documento. Los cambios en las tareas (incluido el estado de finalización) se sincronizan en tiempo real entre los documentos y Lark Tasks.
Lark Docs: redacten, perfeccionen y justifiquen juntos los criterios de aceptación
Redacta la historia de usuario y sus criterios de aceptación en un documento compartido en Lark Docs donde PM, diseño, QA e ingeniería puedan comentar en tiempo real. Utiliza patrones en paralelo: historia en la parte superior, ejemplos de “AC buenos vs malos” debajo y una tabla de “casos límite” para capturar aspectos negativos (por ejemplo, enlace caducado, bloqueo). El historial de versiones mantiene un registro completo de los cambios de redacción y de quién los aprobó; el documento está vinculado de nuevo a la historia base, de modo que los revisores abran la fuente exacta con un solo clic.
Lark Meetings: Reseñas en vivo que producen acción inmediata
Lleva las vistas de Base y el documento de la historia directamente a tu reunión de planificación o refinamiento mediante sesiones de video en Lark Meetings. Recorre el backlog según su preparación: analiza criterios poco claros, edita el texto en el documento en vivo y convierte los resultados en Tareas en Lark Docs. Después de las reuniones, puedes grabar subtítulos y buscarlos o filtrarlos por orador o palabras clave. Además, puedes recortar y compartir momentos clave de las reuniones grabadas para una revisión eficiente.
- Plan inicial: Plan gratuito para siempre que incluye 11 potentes herramientas para hasta 20 usuarios. También incluye 100 GB de almacenamiento, 1000 ejecuciones de automatización, traducciones con IA y más.
- Plan Pro: $12/usuario/mes (facturado anualmente) para hasta 500 usuarios. Incluye todo lo del plan Starter más llamadas grupales para hasta 500 asistentes, 15 TB de almacenamiento, 50,000 ejecuciones de automatización y más.
- Plan Enterprise: Contactar al equipo de ventas para precios personalizados. Admite usuarios ilimitados e incluye aún más ejecuciones de automatización y funciones avanzadas de seguridad, cumplimiento y gestión.
Sección de bonificación: Usa las plantillas de Lark para estandarizar los criterios de aceptación
Estandarizar los criterios de aceptación se vuelve más fácil cuando los equipos trabajan con plantillas consistentes en lugar de comenzar desde cero cada vez. Con Lark, puedes crear plantillas reutilizables de criterios de aceptación que coincidan con tu flujo de trabajo, el formato de las historias de usuario y la terminología. Esto garantiza claridad, reduce el tiempo de redacción y ayuda a los equipos a evitar inconsistencias entre funciones y sprints. Al usar plantillas compartidas en Lark Docs, todos siguen la misma estructura, permitiendo aún así ajustes específicos para cada proyecto.
Lista de verificación de pruebas de aceptación de usuario
Una lista de verificación de Pruebas de Aceptación de Usuario (UAT) asegura que la función cumpla con las necesidades reales de los usuarios antes de su lanzamiento. Primero, confirma que todos los criterios de aceptación estén claramente definidos y aprobados. Durante las pruebas, valida que la función funcione correctamente dentro de los flujos de trabajo reales de los usuarios y que se comporte de manera consistente en todos los dispositivos, navegadores o entornos requeridos. Cualquier problema o retroalimentación del producto debe documentarse junto con las resoluciones esperadas para mantener la transparencia. Finalmente, obtén la aprobación formal de los responsables de negocio o producto para confirmar que está listo para su implementación.
Una plantilla de Pruebas de Aceptación de Usuario (UAT) proporciona una forma estructurada de confirmar que una función o producto cumple con las necesidades reales de los usuarios antes de su lanzamiento. Normalmente incluye campos para los detalles del proyecto, objetivos, criterios de aceptación y escenarios de prueba. Los evaluadores documentan los pasos de cada escenario, los resultados esperados y los resultados reales para garantizar claridad. Cualquier problema u observación se registra para seguimiento y resolución. Finalmente, una sección de aprobación confirma que las partes interesadas del negocio autorizan la función para su liberación.
Recopilación de requisitos
Una plantilla para la recopilación de requisitos ayuda a los equipos a capturar las necesidades del proyecto en un formato estructurado y colaborativo. Centraliza las aportaciones de las partes interesadas, los objetivos empresariales, las expectativas de los usuarios y las limitaciones técnicas en un documento compartido. Los miembros del equipo pueden comentar, perfeccionar y alinearse sobre los requisitos en tiempo real sin confusión de versiones. Las tareas integradas, el chat y las aprobaciones agilizan la discusión y la toma de decisiones. Esto garantiza que todos comiencen el desarrollo con los mismos requisitos claramente acordados.
Mapeo de historias
Una plantilla de mapeo de historias ayuda a los equipos a visualizar el recorrido del usuario y desglosar los objetivos de alto nivel en flujos de trabajo organizados e historias de usuario accionables. Presenta las actividades y tareas en una secuencia lógica, lo que facilita ver las prioridades y dependencias. Los equipos pueden colaborar en tiempo real para perfeccionar los pasos, agrupar funciones e identificar el alcance del MVP. Los comentarios, tareas y documentos vinculados mantienen las discusiones conectadas a cada historia. Esto asegura la alineación sobre qué construir primero y cómo cada función contribuye al valor para el usuario.
¿Por qué son importantes los criterios de aceptación?
Los criterios de aceptación desempeñan un papel crucial en alinear a los equipos con los resultados esperados de una historia de usuario o una funcionalidad. Cuando están bien redactados, actúan como un punto de referencia compartido que define cómo se ve el éxito antes de que comience el desarrollo. Esto evita que los equipos dependan de suposiciones y ayuda a garantizar que los entregables satisfagan las necesidades de los usuarios y los objetivos del negocio. Al hacer explícitas las expectativas, los criterios de aceptación fortalecen la colaboración y mantienen la coherencia en la planificación, el desarrollo y las pruebas.
- Claridad: Los criterios de aceptación definen exactamente qué se debe entregar y cómo debe funcionar. Eliminan las conjeturas al proporcionar resultados medibles. Esta comprensión compartida asegura que todas las partes interesadas interpreten “terminado” de la misma manera.
- Responsabilidad: Hacen que los entregables sean comprobables y transparentes, asegurando que el progreso pueda ser rastreado objetivamente. Cada criterio actúa como un punto de referencia para la finalización. Esto promueve la apropiación y la responsabilidad en todos los roles.
- Aseguramiento de calidad: Los criterios de aceptación sirven como base para los casos de prueba. Proporcionan a los equipos de control de calidad puntos de validación claros para confirmar la funcionalidad. Este enfoque ayuda a detectar problemas de forma temprana, manteniendo la calidad del producto.
- Reducción de retrabajo: Al establecer expectativas explícitas, los criterios de aceptación evitan confusiones y esfuerzos desalineados. Los equipos pueden evitar revisiones innecesarias o cambios en etapas tardías. Esto mantiene el desarrollo eficiente y enfocado en resultados aprobados.
- Mejora de la colaboración: Fomentan un diálogo abierto entre los equipos de negocio, diseño e ingeniería. Todos contribuyen a definir lo que significa el éxito antes de que comience el trabajo. Esta transparencia conduce a una ejecución más fluida y mejores resultados.
Errores comunes que evitar al redactar criterios de aceptación
Criterios de aceptación claros y bien estructurados ayudan a que los equipos se mantengan alineados, pero algunos errores comunes pueden reducir su efectividad. Cuando los criterios son vagos, inconsistentes o se redactan demasiado tarde, los equipos pueden malinterpretar las expectativas y entregar funciones que no cumplen con lo esperado. Al reconocer estos problemas desde el principio, los gerentes de producto, desarrolladores y QA pueden colaborar de manera más efectiva. El objetivo es mantener los criterios de aceptación precisos, comprobables y centrados en el usuario.
- Redactar criterios vagos o subjetivos ("funciona como se espera"): Este tipo de redacción deja la interpretación abierta y no define qué significa “esperado”. Se vuelve difícil para QA verificar los resultados. Sustituya las declaraciones vagas por condiciones específicas y medibles.
- Mezclar múltiples comportamientos en una sola línea: Agrupar múltiples resultados dificulta las pruebas y la claridad. Cada criterio debe representar una acción o resultado comprobable. Divida los flujos complejos en puntos más pequeños e independientes.
- Olvidar casos negativos o extremos: Los criterios de aceptación deben contemplar comportamientos normales, de error y en los límites. Ignorar las rutas de fallo puede llevar a funcionalidades incompletas. Incluya escenarios como entradas inválidas o acceso restringido.
- Redactar criterios de aceptación después de iniciar el desarrollo: Los criterios tardíos provocan retrabajo y expectativas desalineadas. Los criterios de aceptación deben finalizarse antes de la planificación del sprint. Esto asegura que todos comprendan la “definición de terminado” desde el inicio.
- Usar formatos inconsistentes entre equipos: Diferentes redacciones o estructuras pueden generar confusión cuando varios equipos colaboran. Estandarizar los formatos mantiene la comunicación clara y facilita la revisión. Las plantillas o guías compartidas ayudan a mantener la coherencia.
Conclusión
Redactar criterios de aceptación sólidos es esencial para garantizar que todos los involucrados en un proyecto comprendan cómo se ve el éxito. Criterios claros, medibles y enfocados en el usuario ayudan a los equipos a evitar ambigüedades, reducir retrabajos y mantener una calidad constante durante todo el desarrollo. Al elegir el formato adecuado —ya sea Given–When–Then, listas de verificación o basado en reglas— y seguir las mejores prácticas, como alinearse con las partes interesadas desde el inicio y validar de forma colaborativa, los equipos fortalecen la comunicación y la responsabilidad. Evitar errores comunes, como redacción vaga o estructura inconsistente, asegura además que los requisitos se traduzcan sin problemas en funcionalidades operativas.
A medida que los proyectos crecen e involucran a múltiples colaboradores, gestionar los criterios de aceptación en documentos y herramientas dispersos puede volverse abrumador. Aquí es donde Lark aporta un valor excepcional. Con documentos compartidos, control de versiones, colaboración en tiempo real y flujos de aprobación, los equipos pueden revisar, dar seguimiento y perfeccionar los criterios de aceptación sin confusión ni duplicación. Adoptar Lark ayuda a garantizar claridad, alineación y eficiencia, para que los equipos puedan entregar funcionalidades que realmente satisfagan las necesidades del usuario y los objetivos del proyecto.
Preguntas frecuentes
¿Cuál es el mejor formato para redactar criterios de aceptación?
Lark admite múltiples formatos, pero el estilo Dado–Cuando–Entonces (BDD) suele ser el preferido porque describe claramente el contexto, la acción y el resultado esperado. Es especialmente útil para alinear a desarrolladores y control de calidad. Sin embargo, los formatos de lista de verificación funcionan bien para funciones más simples o equipos no técnicos. El mejor formato es aquel que mantiene los criterios claros, comprobables y fáciles de entender.
¿Cuántos criterios de aceptación debe tener una historia de usuario?
No hay un número fijo, pero normalmente de 3 a 7 criterios por historia de usuario es manejable. Cada criterio debe representar un comportamiento o resultado clave. Demasiados criterios pueden indicar que la historia es demasiado grande y necesita dividirse. El enfoque siempre debe mantenerse en la claridad, no en la cantidad.
¿Cuándo deben redactarse los criterios de aceptación en proyectos Ágiles?
Los criterios de aceptación deben definirse antes de la planificación del sprint. Ayudan a garantizar una comprensión compartida antes de que comience el desarrollo. Redactarlos con anticipación reduce la ambigüedad y el retrabajo. Aun así, pueden refinarse de manera colaborativa conforme evolucionen las discusiones.
¿De qué manera Lark ayuda a los equipos a colaborar en los criterios de aceptación?
Lark integra documentos, chat, tareas y flujos de trabajo en un solo espacio compartido. Los equipos pueden comentar, editar y revisar criterios en tiempo real sin confusión de versiones. Las tareas y aprobaciones vinculadas mantienen a todos alineados. Esto hace que la colaboración sea más rápida, clara y transparente.
¿Se pueden actualizar los criterios de aceptación durante un sprint?
Sí, los criterios de aceptación pueden refinarse durante el sprint si surgen nuevos conocimientos. Sin embargo, los cambios deben ser acordados por los equipos de producto, diseño y desarrollo. Cualquier actualización debe mantenerse alineada con la intención original de la historia. Una comunicación clara evita el aumento del alcance y la falta de alineación.
Lecturas relacionadas
Herramientas de planificación de sprint: cómo elijo, implemento y escalo para una entrega predecible
Table of contents
¿Interesado en Lark?
Todas tus herramientas en un solo lugar
Ahorra tiempo y aumenta la eficiencia
Ahorra hasta un 70 % en costos de software
Table of contents
¿Interesado en Lark?
Todas tus herramientas en un solo lugar
Ahorra tiempo y aumenta la eficiencia
Ahorra hasta un 70 % en costos de software
Sigue leyendo
© 2026 Lark Technologies Pte. Ltd.