Historias de Usuario

DEFINICIÓN: Una historia de usuario (o user story en inglés) describe una funcionalidad que,
por sí misma, aporta valor al usuario.

Se compone de:

 una descripción escrita de la historia usada como recordatorio y para planificar. (Debe ser
breve)
 conversaciones acerca de la historia que sirven para aclarar los detalles
 un criterio de aceptación (idealmente automatizado) que permita determinar cuándo la
historia ha sido completada

Una vez estimadas y priorizadas pasan a formar parte de la pila de producto

Formato
Podemos usar tarjetas grandes para las historias de usuario y tarjetas pequeñas (o post-its)
para destacar tareas importantes que no deben olvidarse durante el desarrollo de una “tarjeta
grande”.

Es aconsejable usar el formato: “Como [rol] quiero [funcionalidad] para [beneficio]”

Como [cliente habitual], quiero [ver productos relacionados con mis compras
anteriores] para [ver si hay otros productos que me puedan interesar].

Los criterios de aceptación suelen anotarse en el reverso de la tarjeta.

INVEST

 Independent : se pueden hacer en cualquier orden (no dependen unas de otras)

 Negotiable : no son contratos, sino promesas de comunicación
 Valuable : siempre debemos dar valor al cliente (no crear historias técnicas)
 Estimable : si no podemos estimarlas es porque debemos conversar más
 Small : pequeñas (pero no demasiado)
 Testable : si no puedes probarla, ¿cómo puedes saber que está acabada?

En nuestro ejemplo, los criterios de aceptación se pueden expresar como restricciones:

 Los productos estarán ordenados por valoración y margen de beneficio.

 Cuando el usuario haga clic en un producto, se desplegará el detalle.
 Etc.

Las restricciones que acordemos pueden influir mucho al coste de construcción.

Malas prácticas:

 Escribir historias que dicen cómo se hará en vez de qué se debe hacer (p.ej. CRUD de
Clientes)
 Una Historia de usuario no es un Caso de uso porque no se centra en el cómo ni tampoco
es una definición exhaustiva de los requisitos.
 No escribir el criterio de aceptación o no ser suficientemente explícito.
 No estimar una tarjeta puede crear falsas expectativas y dificulta la autodisciplina.
 Fiar todo a lo escrito en la tarjeta: a veces es necesaria documentación externa. (Wiki)
 Dar una historia por hecha cuando está “prácticamente hecha” en vez de “hecha-hecha”

Ejemplos
Atributos de las historias de usuario (INVEST)

Las Historias de Usuario son peticiones muy sencillas y claras que definen cuales van a ser los
requisitos del proyecto. Es preferible tener un número mayor de historias simples que uno
menor de historias más complejas.

Pero hay una serie de atributos mucho más concretos que las Historias de Usuario deberían
cumplir. Bill Wake en su libro Programming Explored and Refactoring las denomina con el
acrónimo INVEST que se basa en las iniciales de los seis atributos recomendables para las
Historias de Usuario.

 Independent
 Negotiable
 Valuable to users or customers
 Estimatable
 Small
 Testable

A. Independendientes (Independent)

Es razonable evitar la existencia entre dependencias entre las historias, es decir historias que
para estar finalizadas dependen de la finalización de otras. Esto añade un punto más de
complejidad a la planificación de realización de tareas, obligando a estar muy pendiente de estar
interrelaciones y definir una priorización en la realización de las mismas.

Imaginemos las Historias de Usuario a definir para que un cliente pueda realizar el pago con
diferentes tarjetas de crédito:

 Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
 Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard
 Como Jefe de ventas quiero que mis clientes puedan pagar con American Express

Las tres historias están muy relacionadas, además el coste en horas de implementación de cada
una de ellas es dependiente de las otras. Es decir el tiempo para construir la primera puede ser
4 horas y una vez realizada la primera, implementar las otras dos, tendrían un coste
considerablemente menor. Existen dependencias entre las tres historias. La forma de evitarlas
podría ser construir una historia que las englobe:

 Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjetas Visa, Mastercard
y American Express

Si las historias todavía tienen un tamaño elevado, se puede hacer una subdivisión, más
equivalente cuanto a coste
  Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
 Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard y
AmericanExpress

Otra alternativa es que en la estimación de tiempo de cada historia se especifique el coste si se

realiza antes o si se realiza después que otra (Aunque es un mecanismo algo complicado ya que
añade un elemento más a los cálculos de costes).

B. Negotiable (Negociables)

Es una de las bases de la programación ágil, las Historias de Usuario no son unos requisitos
cerrados que permiten cerrar un contrato que no se puedan cambiar. Una Historia de Usuario
es una breve descripción de la funcionalidad que muchas veces se puede utilizar como un
recordatorio. Los detalles de la historia se suelen retrasar hasta los últimos momentos para
precisamente evitar cambios de última hora. Eso no impide que si en el momento de redactar
la base de la historia, se conoce algún detalle se pueda anotar en la misma tarjeta toda la
información que se conozca (aunque suele ser sensato contrastarla en el momento que sea
necesario).

En este caso el cliente (el jefe de ventas) puede considerar en el momento de la entrevista que
solo se admitan dos tarjetas aunque es razonable contemplar en la implementación que es
posible que se incorporen más.

Si se dispone de más información del requisito es bueno tomar nota de él. El reverso de la tarjeta
es un lugar ideal para acompañar detalles útiles en la implementación.

La tarjeta es un recordatorio, personalmente yo recomiendo apuntar detalles que generan duda

o incertidumbres a contrastar directamente, hay que olvidar el famoso dicho de “no hace falta
apuntarlo ya que ya lo recordaré”. Es bueno tomar nota, e incluso subrayar si es necesario
realizar una consulta a otras personas. Estas pequeñas notas en el reverso pueden ayudar en la
segunda entrevista al usuario.

C. Valuable (Con valor para el usuario)

Es uno de los aspectos más controvertidos sobre las Historias de Usuario. Hay quién indica que
las historias deben aportar valor al usuario y por eso es razonable que el usuario las pida
directamente. Yo considero que todas las historias que se implementen deben tener valor para
el usuario aunque éste inicialmente no lo sepa.

El usuario debería estar seguro que todas las historias le aportan valor. En general, temas de
seguridad a muchos niveles no les preocupan (no porque no lo consideren importante, sino
porque a veces lo dan por hecho). Las Historias de Usuario deben aportar valor, en general se
definen en base a peticiones del usuario, no obstante cabe la posibilidad de definir historias de
usuario a partir de criterios técnicos por parte del equipo. Es estos casos es necesario que se
explique correctamente al usuario los motivos de necesidad de estas.
D. Estimatable (Estimable)

El equipo de desarrollo debe poder estimar el coste (al menos aproximado) de desarrollar cada
una de las Historias de Usuario. Es un requisito fundamental para poder planificar de manera
razonable las historias que se pueden desarrollar dentro de un Sprint. La forma de medir el coste
puede ser las horas de desarrollador o los puntos de historia (tratados en capítulos anteriores)

Es posible que el coste de una historia no pueda ser calculada con un nivel de precisión
razonable, los motivos habituales por los que esto pueda ocurrir son

El equipo de desarrollo no conoce el dominio. Ya se comentará en el tema de la entrevista.

Obviamente el equipo de desarrollo no puede pretender tener el mismo conocimiento que tiene
el cliente del entorno de trabajo de éste. Aun así, es conveniente adquirir unas bases que
permitan, en primer lugar dar confianza al cliente, y en segundo lugar abordar con el suficiente
conocimiento los desarrollos a realizar.

El equipo de desarrollo no tiene conocimientos técnicos del entorno. También puede ocurrir que
el equipo de desarrollo deba trabajar en un entorno de programación o base de datos novedoso
(al menos para ellos) que puede hacer que estimen sin un nivel de confianza lo suficientemente
alto. Es este caso se agradece la aportación de expertos en el entorno que pueden hacer ver las
comparaciones de costes con entornos mejor conocidos por el equipo de desarrollo. Si no se
dispone de ningún experto, es razonable que algunos miembros del equipo profundicen de
manera rápida en el tema. Esta profundización debe contar como una historia más, ya que tiene
su coste en horas.

La historia es demasiado compleja o tiene un tamaño muy grande. Este caso es el más sencillo
de resolver, se debe dividir la historia en dos o más historias de menor tamaño que puedas ser
estimadas con mejor precisión.

E. Small (Pequeña)

El concepto pequeña es muy relativo, pero entendemos como que la Historia de Usuario debe
tener una duración que la haga lo suficiente manejable para el equipo. Pequeña no debe
confundirse con microscópica, ya que tener un sinfín de cientos de historias microscópicas
puede convertir en un infierno la planificación y la integración de todas en el proyecto final.

Es razonable que el equipo de desarrollo defina un coste razonable para las Historias de Usuario
estándar con las que van a trabajar. Algunos hablan de semana/programador como el tiempo
máximo, mientras otros equipos prefieren definir como un día/programador como un coste
medio razonable.

Una historia que fuera como jefe de ventas quiero una “gestión web de las ventas para
incrementarlas” tiene una dificultad considerable para ser estimada.
Debiera poder dividirse inicialmente en gestión de usuarios, de productos y en sí de la venta.
Aun así cada una de ellas tiene una complejidad elevada. Es posible que la gestión de usuarios
al ser bastante estándar pudiera (quizá no debiera) quedar como una historia.

Es más razonable definir historias del tipo:

 Como jefe de ventas quiero poder dar de alta un producto para venta
 Como jefe de ventas quiero poder modificar características de un producto o eliminarlo
 Como jefe comercial quiero poder añadir campaña comerciales que afecten al precio de
venta del producto

Un modelo de historias de este tipo es que permite de manera sencilla estimar el coste de cada
historia e incluso permite que el cliente pueda priorizar entre las mismas. Así podemos iniciar
una página de venta con productos y más adelante permitir la incorporación de campañas
comerciales de diverso tipo.

La gestión de usuarios, bastante estandarizada puede ser considerada como una única historia
de usuario más allá de historias del tipo:

 Como jefe de ventas quiero poder dar de alta un usuario

 Como jefe de ventas quiero poder modificar un usuario
 Como jefe de ventas quiero poder dar de baja un usuario
 Como jefe de ventas quiero poder consultar un usuario

Pero no hay que olvidar que el concepto de Small (pequeño) es muy dependiente de como el
equipo de desarrollo se sienta cómodo. En sí lo que si debe garantizar al cien por cien es que
toda historia de usuario debe ser estimable y deba tener un coste mínimo algo más alto que el
tiempo que se pierda en hablar de ella.

F. Testable (Se puede validar)

Otro de los conceptos que hemos visto como un tema fundamental es el de terminado. Una
historia debe tener unos objetivos claros, y deben ser tan claros que deba ser posible comprobar
que el trabajo ha cumplido las expectativas, es decir que se pueda validar el trabajo realizado.

Otro de los objetivos es que el mayor número de historias se pueda validar de forma automática,
por lo que es muy interesante utilizar conjuntos de aplicaciones de prueba que así lo permitan.
En ocasiones, esto es complicado, pero hay que definir claramente una batería de pruebas que
pueda ser realizada para verificar lo correcto de un programa o módulo. El coste de realizar las
pruebas se debe incluir en el coste de la historia de usuario, a menos que haya alguna historia
que tenga como objetivo la realización de una serie de pruebas de conjunto.
Sólo los requisitos no funcionales como pueda ser “conseguir un Interfaz amigable o facilidad de
uso para usuario novel” pueden evitar la definición de esas baterías de prueba. No obstante se
pueden definir tareas más complejas que exceden al equipo de desarrollo y que permitan hacer
una estimación del grado de resolución de algunos requisitos no funcionales.

Algunos Ejemplos de Historias de usuarios

Historia de usuario - Listado de morosos

YO COMO gerente de sucursal

DESEO el listado de morosos
PARA saber a quien comenzar a cobrar

---Criterios de aceptación
- El listado contendrá los campos
- Nombres
- Apellidos
 - Cédula
- dias de mora
- monto
- tipo de préstamo
- El listado debe estar ordenado x días de mora descendente
- Quienes tengan mora
- mayor a180 dias en color rojo
- 60-179 color amarillo
- color negro
- Exportable a Excel 2010
- Paginado por cada 20 registros
- Accede solo el Gerente de sucursal
- En la parte superior de reporte debe aparecer la fecha de corte (fecha en que se genera)
Conclusiones

Las Historias de Usuario son una forma de acercar el lenguaje del usuario al desarrollador, de
forma que se permita hablar un mismo lenguaje ambos y se eviten ambigüedades que puedan
suponer pérdidas de tiempo notables.

Lo importante de las historias es que reflejen de forma sencilla lo que el usuario quiere, “El qué”
y no “el cómo”. Es importante que sean muy claras y con criterios de validación muy concretos.
Durante el proceso, las historias pasarán a ser grandes trabajos a realizar muy generalmente
especificados, hasta ser tareas concretamente detalladas, pero es un proceso por fases, que
permite detallar la tarea junto con el cliente cuando se van a implementar.