Historias de Usuario

¿Qué son las Historias de Usuario?

Las historias de usuario de Scrum es uno de los elementos principales a definir, antes de

comenzar un Sprint en esta metodología ágil de gestión de proyectos. Una historia de
usuario bien redactada, permitirá definir los beneficios que traerá el producto a su público
objetivo.
“Se podría decir que son el elemento mínimo que conforma un proyecto en metodología
ágil. Condensan los requisitos del cliente, lo definen y ayudan a comprender al equipo, el
por qué están construyendo.”
Product
owner
Cliente
 Beneficios:

Mejoran la estimación y planificación de los demás sprints. Se almacenan en el backlog

para aprender a gestionar el trabajo en curso (WIP, o Work In Progress) y perfeccionar aún
más el flujo de trabajo.

Otro de los beneficios de las User Stories es que pueden escribirse con distintos niveles de
detalle. La longitud determina la funcionalidad que se desea abarcar. Cuando se llegan a
tener grandes historias de usuario generalmente pasan a categoría de “épicas” (Epics).
 Estructura de Historias de Usuario

Las historias de usuario es una descripción de una función que deberá tener el producto final (ya sea o no un
software). Esta descripción está redactada en forma natural y sencilla, en lenguaje informal. Debe resumir allí, la idea
de lo que espera obtener el cliente, en cada función del producto. Es decir, que debe incluir la perspectiva del
usuario final.
Su estructura básica es:

También se puede ampliar su estructura de la siguiente forma:

• Título
• Descripción
• Criterios de aceptación
• Prioridad
• Trabajo relacionado
 ¿Para qué sirven las historias de usuario?
Las historias de los usuarios describen el por qué y el qué hay detrás del trabajo diario de
los miembros del equipo de desarrollo, mediante un enfoque visual que permite ver,
priorizar y evaluar los requisitos.

Asimismo, son una forma muy práctica de definir el alcance de un proyecto sin necesidad
de utilizar un lenguaje técnico. Otros beneficios de las historias de usuario:
 Ayuda a alinear expectativas de todos los participantes
 Fomenta el trabajo en equipo y la integración de expertises
 Aumenta la satisfacción del usuario
 Impulsan soluciones creativas
 Reducen errores a futuro
 ¿Por qué usar las historias de usuario?
Para proyectar en grande una idea es necesario contar con diversas estructuras que ayuden a
organizar los entregables desde el de mayor importancia hasta los subsecuentes. También,
entre toda la planeación, debes ser capaz de responder a los cambios y abrirte a las opiniones
de los demás.

Aquí es donde los epics, las historias y las iniciativas son, exactamente, las metodologías
ágiles y de DevOps que ayudarán a su empresa a organizar el trabajo y lograr un equilibrio
saludable entre estructura, flexibilidad y eficacia. Usaremos el storytelling para contar la
historia de nuestro producto.

 Historias de usuario son breves indicaciones o solicitudes escritas desde el punto de vista
del usuario final.
 Epicas (proyectos de mayor volumen): Son grandes cantidades de trabajo que se pueden
desglosar en un número de tareas más pequeñas, ya sea desde historias hasta subhistorias.
 Iniciativas: Son conjuntos de epics e historias de usuario que conforman la totalidad del
proyecto.
 ¿Cómo construir una historia de usuario?
Debes describir el rol, la funcionalidad y el resultado esperado en una frase corta. Debe
venir acompañada (al reverso) de los criterios de aceptación, estos permiten definir las
pruebas a realizar para poder verificar su aceptación.
Debe haber hasta un máximo de 4 criterios por historia, redactado también en una frase el
contexto, el evento y el comportamiento esperado ante ese evento.
De esta forma, la historia de usuario entregará el valor esperado por el Product Owner.

Las historias de usuario pueden escribirse en forma de fichas, o si se trata de algo más
informal, en post it. Aunque la mejor forma de hacerlo, es dentro de un software de
gestión de proyectos. Estas herramientas ofrecen marcos predeterminados con informes,
monitoreo , notificaciones y herramientas de comunicación para que el equipo pueda
gestionar el proyecto Scrum de forma más efectiva. Algunos de los Software Scrum, que
ofrecen estas opciones son Monday, Kendis u Oracle Primavera.
3 estructuras fundamentales para la redacción de historias de usuario:
1# Regla de las 3’Cs
3 estructuras fundamentales para la redacción de historias de usuario:
2# Como [perfil], [quiero] [para]
3 estructuras fundamentales para la redacción de historias de usuario:
3# Given – When – Then (Pruebas de aceptación)

Dado (escenario o
precondiciones)

Cuando (condiciones de las

acciones a ejecutar)

Entonces (resultado
esperado o
validaciones a
realizar)
 Descripción de una historia de usuario:

• Definir quién utilizará el requisito de esta historia

En el como, que es en realidad el quien, es importante definir al usuario objetivo de forma
detallada: ocupación, conocimientos de informática, cómo y dónde vive, cómo usará el
producto, etc.

• Especificar qué quiere el usuario y para qué

Las historias de usuario deben describir cómo se va a resolver el problema del usuario, y cómo
usará esta solución.

• Se debe establecer el objetivo de construcción de esta funcionalidad.

• Las condiciones de aceptación de la historia de usuario

Estas son las características que debe cumplir el producto al final del Sprint, para considerarse
terminada expectativa de diseño, usabilidad, rendimiento, y la satisfacción del usuario.
 Ejemplos:

La estructura fundamental de las plantillas de historias de usuarios, sigue el siguiente orden: Título-Como
(Quien)- Quiero- Para- Condiciones.

Ejemplo 1:
Como futuro usuario del sistema, quiero poder registrar a los clientes en un archivo, para iniciar una
campaña de e-mail marketing.

Ejemplo 2:
-Como usuario de la aplicación móvil del banco
-Quiero visualizar mi posición global en la página de entrada
-Para saber si dispongo de saldo suficiente nada más acceder sin navegar por menús

Ejemplo 3:
Como director de ventas, quiero registrar los ingresos y cantidades que me solicitan mis clientes para
trazar una estrategia comercial con mis proveedores.
Descripción del Sistema INVEST para recordar cómo escribir historias de usuarios en Scrum:

El investigador Bill Wike, ha definido una regla mnemotécnica a la hora de pensar cómo
escribir historias de usuarios en Scrum. Se trata del modelo INVEST. Según este modelo las
historias de usuario deben ser:
 Épicas vs Historias
Las historias de usuario pueden crearse con distintos niveles de detalle. Podemos escribir
historias que comprendan un gran número de funcionalidades relacionadas. Este tipo de
historias de gran tamaño suelen denominarse “Épicas”. Volviendo a nuestro ejemplo de
una aplicación de banca para móvil, podríamos tener una épica que fuese:

 Como: usuario de la aplicación móvil del banco

 Quiero: programar una transferencia periódica
 Para: poder pagar una cantidad mensual, semanal, etc.
Las épicas son normalmente bloques funcionales demasiado grandes como para que
equipo ágil pueda completarlos en una iteración, esto es, dentro de un sprint en Scrum.
Por eso es necesario dividirlas en historias de usuario más pequeñas.
 Criterios de Aceptación

Los criterios de aceptación son una parte fundamental de las historias de usuario, puesto
que permiten definir las pruebas a realizar para poder verificar su aceptación, esto es, que
una vez terminada, la historia de usuario entrega el valor esperado por el Product Ownery
se deben indicar en un lenguaje claro, conciso y en términos de negocio las condiciones
que deben cumplirse para que una historia se acepte como terminada.
 ¿Quién se encarga de hacerlas?

Quien tiene la autoridad sobre el backlog, como se priorizan las historias, que esta incluido
y que no y quien lo da por validado es el Product Owner. Lo que es en sí la creación,
aunque en algunas situaciones lo realiza solo el Product Owner, la realidad nos dice que
suele ser realizado por el Product Owner junto con el Business Analyst si existe la figura
especifica y si no existe, junto el Development Team, que asume ese trabajo como un rol
mas dentro del equipo.

Estas se definen mejor en la ceremonia llamada Grooming o refinamiento, la cual sirve

para aclarar dudas y poder otorgar una estimación de esfuerzo/tiempo mejor.