Criterios de aceptación en una historia de usuario: los errores que los equipos cometen con más frecuencia
Los criterios de aceptación definen las condiciones bajo las cuales el Product Owner considera terminado un elemento del Product Backlog. Es el contrato entre el Product Owner y el Equipo de Desarrollo para un elemento específico.
Los errores
Error 1: Demasiado vagos para ser comprobables. "Funciona correctamente" no es un criterio de aceptación. "El usuario recibe un correo de confirmación en 60 segundos tras enviar el formulario" sí lo es.
Error 2: Escritos después de que comienza el desarrollo. Cuando los criterios se escriben después de que el desarrollo ha comenzado, describen lo que se construyó en lugar de lo que se necesitaba. Solución: deben revisarse y acordarse antes de que termine el Sprint Planning.
Error 3: Comprobables pero no desde la perspectiva del usuario. "La API devuelve un código de estado 200" es comprobable; también es inútil como criterio de aceptación a menos que la respuesta sea el valor que recibe el usuario.
Error 4: Casos límite y estados de error faltantes. Los criterios del camino feliz describen qué pasa cuando todo funciona. La mayoría de los defectos ocurren en casos límite: ¿qué pasa cuando la red es lenta, un campo está vacío?
Error 5: No revisados por el Equipo de Desarrollo antes del Sprint. Los criterios que el equipo no ha leído antes del Sprint Planning generarán sorpresas durante el Sprint. Esta revisión es parte del Refinamiento del Backlog.
XNM apoya a organizaciones en el desarrollo de prácticas Scrum efectivas. Comuníquese con el equipo de asesoría en entrega de programas y proyectos de XNM para apoyo en su entrega ágil.