Historias de Usuario
Las Historias de Usuario (User History) son la forma recomendada en entornos ágiles para escribir los requisitos del producto expresados por los usuarios. Dado que son afirmaciones breves, simples y fáciles de entender, resultan en una mejor comunicación entre los Stakeholders y el equipo Scrum.
Al redactar una Historia de Usuario se debe tener en cuenta describir el rol, la funcionalidad y el resultado esperado en una frase corta. Debe venir acompañada de los criterios de aceptación que debe cumplir la Historia de Usuario.
Las Historias de Usuarios centran la atención en los usuarios finales, por lo que no utilizan un lenguaje técnico, con el fin de facilitar el entendimiento para los usuarios y asimismo ofrecer un contexto suficiente para guiar el esfuerzo de los Developers.
“Las historias centran la atención en el usuario. Una lista de tareas pendientes mantiene al equipo centrado en tareas que deben completarse, pero un conjunto de historias lo mantiene centrado en solucionar problemas para usuarios reales.”
Estructura de una Historia de Usuario
Las Historias de Usuario suelen expresarse como una frase simple y breve que cumple con la siguiente estructura:
Como: Describe el Rol del Stakeholder que solicita (o usaría) la funcionalidad o requerimiento.
Quiero: Describe la necesidad o requerimiento del usuario, por lo general, es una frase corta.
Para: Describe el beneficio esperado por el Stakeholder una vez se desarrolle el requerimiento
Ejemplos de Historias de Usuario
Como: Cliente, Quiero: pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria o tarjeta de crédito, Para: evitar el desplazamiento hasta la sucursal de pago.
Como: Supervisor de ventas, Quiero: consultar un listado de los pedidos de venta que han sido registrados y aún no han sido procesados, Para: Tener un reporte detallado a la mano.
Como: Ejecutivo de cuenta, Quiero: consultar los datos de un cliente suministrándole al sistema únicamnte su documento de identidad o código de cliente, Para: facilitar el proceso de busqueda y reducir el tiempo de atencion.
Como: asesor de ventas, Quiero: disponer de una diadema inalámbrica, Para: poder levantarme regularmente de mi puesto y disminuir el estrés y el cansancio.
Componentes adicionales de una Historia de Usuario
Una Historia de Usuario puede tener componentes adicionales que permitan mejorar su entendimiento tanto para el usuario como para los Developers. Usualmente estos componentes son:
- Criterios de aceptación (detalle técnico)
- Estimaciones
- Criterios de prueba
- Prototipos, Diagramas, etc.
1. Criterios de aceptación (detalle técnico)
Microsoft define a los criterios de aceptación como las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o stakeholder.
Para Google, son estándares pre-establecidos o requerimientos que un producto o proyecto debe satisfacer.
Concretamente en Scrum, se los define como un conjunto de sentencias redactadas de tal manera que conduzcan a una respuesta clara de “aceptado/rechazado”. Detallan las especificaciones técnicas de cada Historia de usuario o Tarea.
El Product Owner es el responsable de redactar los criterios de aceptación para cada Historia de Usuario en conjunto con el cliente y/o los interesados, para posteriormente confirmarlos con los Developers antes de desarrollar la Historia de Usuario. Esta confirmación se realiza durante la Reunión de Planificación del Sprint (Ceremonias).
Los criterios de aceptación ayudan a los Developers a entender el funcionamiento del producto, de manera que estimarán mejor el trabajo necesario, además de servir como guía para tomar decisiones más acertadas de acuerdo a lo que se espera de la Historia de Usuario.
Un criterio de aceptación debe poder probarse o testearse, cuando no es posible probar algun criterio de aceptación es un claro indicio de una mala redacción del mismo. Se debe tener en cuenta que al probar una Historia de Usuario frente a un criterio de aceptación se obtiene una respuesta binaria: Cumple o No cumple; no existe el concepto de cumplir parcialmente un criterio de aceptación.
Algunos beneficios de contar con buenos criterios de aceptación:
- Permite que los Developers entiendan una funcionalidad desde la perspectiva del usuario.
- Reduce las ambigüedades al desarrollar las Historias de Usuario.
- Promueve la calidad del producto permitiendo que los Developers se adhieran a los criterios de aceptación antes de una demostración de los resultados.
- Permiten confirmar si una Historia de Usuario se comporta de acuerdo a lo esperado.
Una manera opcional de construir los criterios de aceptación es la siguiente:
Cuando (Rol) hace (Acción) consigue (Resultado / Comportamiento esperado)
Algunos ejemplos:
- Cuando el cliente (Rol) pide dinero (Acción), si hay saldo positivo, el dinero se debita de la cuenta y es entregado al cliente.
- Cuando el cliente (Rol) pide dinero (Acción), si hay saldo negativo, se muestra mensaje "Saldo no disponible", y no se entrega el dinero al cliente.