Historias de Usuario

Definición

Las historias de usuario (HU) son un formato conveniente para expresar las características deseadas de un sistema que le aportan valor a un usuario. Las historias de usuario se crean de tal forma que sean comprensibles para todos los stakeholders (clientes, usuarios, desarrolladores).

Las HU son simples y se pueden escribir en varios niveles de granularidad para refinarlas progresivamente.

Una HU se debe poder escribir en una tarjeta de 7 x 12 cm, usando el siguiente patrón lingüístico:

"Como un rol del usuario quiero objetivo para beneficio".

Un ejemplo de una historia de usuario sería el siguiente:

Ver comentarios de restaurantes cercanos
Como cliente del restaurante quiero ver los comentarios de restaurantes cercanos para reservar uno en particular.

Como se observa, las tarjetas no están destinadas a capturar toda la información del requisito. De hecho, se usan deliberadamente tarjetas pequeñas con espacio limitado para promocionar la brevedad. Una tarjeta debe contener algunas frases que capturen la esencia o la intención de un requisito. Por tanto, sirven como marcador de posición para discusiones más detalladas que tomarán lugar entre las partes interesadas, el propietario del producto y el equipo de desarrollo.

Una historia de usuario también contiene información de confirmación en forma de criterios de aceptación (CA), los cuales aclaran el comportamiento deseado. Estos son utilizados por el equipo de desarrollo para comprender mejor qué construir y probar y por el propietario del producto para confirmar que la historia de usuario se ha implementado a satisfacción.

Si el anverso de la carta tiene una descripción de unas pocas líneas de la HU, el reverso de la carta podría especificar criterios de aceptación, que pueden expresarse como pruebas de aceptación de alto nivel.

Los CA son una forma importante de capturar y comunicar, desde la perspectiva del propietario del producto, cómo determinar si la historia se ha implementado correctamente.

Los CA también pueden ser una forma útil de crear historias iniciales y refinarlas a medida que se conocen más detalles. Este enfoque a veces se denomina Acceptance-Test-Driven Development (ATTD)(ATTD).

A continuación se presenta una historia de usuario junto con sus criterios de aceptación.

Subir archivos
Como usuario de la Wiki quiero subir archivos para compartirlos con mis colegas.

Criterios de aceptación
- Verificar que los documentos de texto tengan extensiones .txt o .doc
- Verificar que las imágenes tengan extensiones .jpg, .gif o .png
- Verficar que los videos tengan extensión .mp4 y un tamaño menor a 1 GB
- Verificar que el archivo no tenga restricciones de DRM

INVEST

¿Cómo sabemos si las historias que hemos escrito son buenas historias?

Bill Wake ha definido seis criterios útiles para evaluar si nuestras historias son aptas para el uso previsto o si requieren algun trabajo adicional.

Esos criterios están representados por el acrónimo INVEST: Independiente, Negociable, Valiosa, Estimable, Pequeña (small: del tamaño adecuado) y comprobable (testeable).

Independiente

Las historias de usuario deben ser independientes o muy poco acopladas entre sí. Las historias que muestran un alto grado de interdependencia complican la estimación, la priorización y la planificación.

Negociable

Los detalles de las historias deberían ser negociables. Las historias no son un contrato escrito; por el contrario, las historias son marcadores de posición para las conversaciones donde se negociarán los detalles. Las buenas historias capturan claramente la esencia de la funcionalidad deseada pero dejan espacio para que el propietario del producto, las partes interesadas y el equipo negocien los detalles.

Valiosa

Las historias deben ser valiosas para un cliente, un usuario o ambos. Si una historia no es valiosa para ninguno de los dos, no pertenece al listado de productos a desarrollar (product backlog).

Estimable

Las historias deben ser estimables por el equipo que las diseñará, construirá y probará. Las estimaciones proporcionan una indicación del tamaño y, por lo tanto, del esfuerzo y costo de las historias. De este modo, las historias más grandes requieren más esfuerzo y, por lo tanto, cuesta más dinero desarrollarlas que las historias más pequeñas.

Pequeña (del tamaño adecuado)

Las historias deben tener el tamaño adecuado para cuando planeamos trabajar en ellas. Si estamos haciendo un sprint de varias semanas, queremos trabajar en varias historias que tengan unos pocos días de duración. Si tenemos un sprint de dos semanas, no queremos una historia de dos semanas, porque el riesgo de no terminar la historia es alto.

Testeable

Las historias deben ser comprobables de forma binaria: pasan o no sus correspondientes pruebas. Ser testable significa tener buenos criterios de aceptación (relacionados con las condiciones de satisfacción) asociados con la historia.