4.3 - 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 únicamente su documento de identidad o código de cliente, Para: facilitar el proceso de búsqueda y reducir el tiempo de atención.
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
- 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 con lo que se espera de la Historia de Usuario.
Un criterio de aceptación debe poder probarse o testearse, cuando no es posible probar algún criterio de aceptación es un claro indicio de una mala redacción de este. 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 con 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.
2. Estimaciones
Es muy importante realizar la estimación del trabajo requerido para desarrollar las Historias de Usuario y las tareas relacionadas, de esta manera se logran planificaciones más precisas.
La estimación no la determina el cliente o el Product Owner, sino los Developers en conjunto con el Scrum Master y el Product Owner, ya que ellos son quienes ejecutarán directamente el trabajo necesario.
Para garantizar una estimación más precisa, se pueden considerar elementos como:
- Dificultad / complejidad: Hace referencia a qué tanto esfuerzo se requiere para ejecutar determinado trabajo. Se utilizan los Puntos de historia como unidad de medida.
- Duración: Hace referencia a cuánto tiempo se requiere para ejecutar determinado trabajo. Se puede utilizar horas o días como unidad de medida.
- Costo: Hace referencia al dinero requerido para la ejecución de un determinado trabajo, el cual se calcula a partir del trabajo de los developers más los recursos necesarios para su ejecución.
Uno de los problemas más comunes con la estimación de las historias de usuario, es sólo se estimar la dificultad (puntos de historia), o sólo estimar la duración (horas / días); por lo que es altamente recomendable estimar los dos. Muchos equipos prefieren unificar esto mediante una relación entre los puntos de historia y la duración, es decir que para cada punto de historia se asigna un tiempo determinado.
El manejo de puntos de historia es específico de cada equipo, no es recomendable comparar diferentes equipos basados en sus estimaciones (aunque sean equipos del mismo proyecto) ya que cada equipo tiene diferente capacidad de trabajo.
A continuación se muestra un ejemplo de ello:
Un equipo A definió la siguiente tabla de estimaciones para el proyecto en el que esta trabajando actualmente:
El equipo B definió la siguiente tabla de estimaciones para su proyecto:
3. Prototipos, Diagramas, etc
Los prototipos, diagramas, esquemas de una Historia de Usuario nos sirven para mostrar un acercamiento al resultado que se espera obtener en cuanto los Developers ejecuten su trabajo, de esta manera se puede probar el producto antes de construirlo para identificar posibles errores y generar un mejor entendimiento para los Developers.
- Permiten a los Developers desarrollar su trabajo en torno a una guia clara sobre las expectativas del cliente/usuario final.
- Constituyen un gran apoyo para lograr mejores estimaciones de trabajo.
- Son más fáciles de abordar con los usuarios finales.
- Permite que el usuario se sienta involucrado en construcción del producto, ya que puede "verlo por adelantado".
- Se reduce el riesgo o la incertidumbre sobre el resultado de producto esperado.
Épica
Es comun que existan Historias de Usuario de gran tamaño y/o gran complejidad Cuando se permiten agrupar los elementos del Product Backlog, permitiendo una mejor navegación por el mismo. Algunas ideas de las que se podrían definir las épicas son: • Módulos. • Componentes. • Hitos. • Entregables. • Funcionalidades.
Una épica no es más que un nivel de agrupación por encima de las historias de usuario que permite clasificar las mismas por funcionalidades, módulos, subsistemas, etc. En muchas ocasiones las épicas, son demasiado largas (o complejas) para ser completadas en un solo Sprint