historias de usuario: Guía para principiantes sobre criterios de aceptación

ara completar una historia de usuario ágil. Especifican los límites de la historia y se utilizan para confirmar cuándo está funcionando según lo previsto. Aquí hay una guía introductoria para escribir y usar criterios de aceptación.,

lista de verificación de criterios de aceptación

descubra las 13 características de effective acceptance criteria

asegúrese de que sus criterios de aceptación proporcionen historias de usuario valiosas y un producto valioso.

la semana pasada describí los huesos de la historia de usuario en el primer post de nuestra serie introductoria sobre historias de usuario. En resumen, una historia de usuario es una descripción de un objetivo que una persona debe ser capaz de lograr al usar su sitio web/aplicación/software. Estas historias a menudo se escriben en este formato: como un quiero para que .,

por ejemplo: como miembro de Flickr quiero poder asignar diferentes niveles de privacidad a mis fotos para poder controlar con quién comparto qué fotos.

este post añade algo de carne a la idea de las historias de usuario, en forma de criterios de aceptación.

¿dónde están los detalles?

a primera vista, puede parecer que las historias de usuario no proporcionan suficiente información para que un equipo pase de una idea a un producto. Ahí es donde entran los criterios de aceptación. Pero primero, aquí hay algunos antecedentes., En 2001, Ron Jeffries escribió sobre las tres C de la historia de usuario:

• Las historias de tarjetas se escriben tradicionalmente en tarjetas de notas, y estas tarjetas se pueden anotar con detalles adicionales
• conversación: los detalles detrás de la historia salen a través de conversaciones con el propietario del producto
• Confirmación: las pruebas de aceptación confirman que la historia está terminada y funciona según lo previsto.

en un proyecto que sigue un proceso ágil, el equipo de desarrollo discute historias de usuarios en reuniones con el propietario del producto., (El propietario del producto es la persona que representa al cliente para la cosa que está desarrollando, y que escribe las historias de usuario). Primero el propietario del producto presenta la historia del usuario, luego comienza la conversación.

por ejemplo: como asistente a una conferencia, quiero poder registrarme en línea, para poder registrarme rápidamente y reducir el papeleo.

en este caso, las preguntas para el propietario del producto podrían incluir:

• ¿Qué información se debe recopilar para permitir que un usuario se registre?
• ¿Dónde se debe recopilar/entregar esta información?,
• ¿Puede el usuario pagar en línea como parte del proceso de registro?
• ¿Es necesario enviar un acuse de recibo al usuario?

usted captura los problemas e ideas planteadas en esta sesión de preguntas y respuestas en los criterios de aceptación de la historia.

criterios de aceptación de ejemplo

los criterios de aceptación definen los límites de una historia de usuario y se utilizan para confirmar cuándo se completa una historia y funciona según lo previsto.

para el ejemplo anterior, los criterios de aceptación podrían incluir:

• Un usuario no puede enviar un formulario sin completar todos los campos obligatorios.,
• La Información del formulario se almacena en la base de datos de Registros.
• La protección contra el spam está funcionando.
• Los usuarios pueden pagar con tarjeta de crédito.
• se envía un correo electrónico de confirmación al usuario después de enviar el formulario.

así que como puedes ver, escribes criterios de aceptación en un lenguaje simple, al igual que la historia del usuario. Cuando el equipo de desarrollo ha terminado de trabajar en la historia del usuario, demuestran la funcionalidad al propietario del producto. Al hacer esto, muestran cómo han satisfecho cada uno de los criterios.,

obtener más ejemplos de criterios de aceptación

para obtener más ejemplos, puede descargar nuestro PDF de ejemplos de historias de usuario.

criterios de aceptación y la definición de done

Las personas a veces no están seguras de la diferencia entre los criterios de aceptación y la definición de done. La diferencia clave es que la definición de hecho se aplica a todo su trabajo, mientras que los criterios de aceptación son específicos para historias individuales.

Obtenga más información sobre la diferencia entre la definición de hecho y los criterios de aceptación.,

beneficios de usar criterios de aceptación

incluir criterios de aceptación como parte de sus historias de usuario tiene varios beneficios. Ellos:

• hacen que el equipo piense cómo funcionará una característica o pieza de funcionalidad desde la perspectiva del usuario
• eliminar la ambigüedad de los requisitos
• Formar las pruebas que confirmarán que una característica o pieza de funcionalidad está funcionando y completa.,

Introducción a las historias de usuario — serie de blogs

1. guía para principiantes de historias de usuario
2. agregar criterios de aceptación a las historias de usuario
3. historias de usuario y el proceso de desarrollo
4. casos de uso vs historias de usuario
5. incorporar a las partes interesadas a través de historias de usuario
6. crear historias de usuario con mapeo de historias
7. Mejorar las historias de usuario con una definición de listo
8. Ejemplos de historias de usuario

lectura adicional

realmente recomiendo este post de Sandy Mamoli., (Sandy es un entrenador ágil de Wellington y maestro de scrum, con quien trabajamos en Digital New Zealand). Después de eso, te gustaría ver esta presentación sobre historias de usuarios efectivas de Mike Cohn. Si estás trabajando en Scrum, esta publicación muestra cómo agregar criterios de aceptación cuando estás creando historias de usuarios en Scrum.

Iniciar un nuevo proyecto? Echa un vistazo a nuestro kit de inicio de proyecto ágil para aprender sobre el mapeo de historias de usuario y la priorización de historias de usuario durante el descubrimiento de proyectos.