18/10/2018 Scrum.

Historias de Usuario – Ingeniería Ágil

Ingeniería Ágil
Et in Arcadia Ego

Scrum. Historias de Usuario

La comunicación
El proyecto software que un equipo de desarrollo va a realizar en la mayoría de los
casos no responde a una idea suya sino más bien a las necesidades que alguien (los
usuarios) tienen. Los usuarios deben indicar lo que quieren resolver a otra persona
(en el modelo tradicional un analista), éste a su vez captura lo que él ha entendido
como requisitos del usuario y describe en forma de análisis de requisitos o funcional
u algún modelo similar, lo que él ha entendido. Ese trabajo acabará nalmente en
unas indicaciones más o menos concretas para que el equipo de desarrollo
nalmente implemente el proyecto.

http://fernandollopis.dlsi.ua.es/?p=39 1/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

Una de las mayores preocupaciones es que el analista que capta las peticiones del
usuario, suele terminar transmitiéndolas en un documento de difícil compresión
para éste. Así en general los completos documentos de análisis de una aplicación
rara vez suelen ser entendidos por los usuarios, que en general suelen basarse en lo
que ellos aseguran que dijeron más allá de lo que especi que el documento de
análisis.

Además, otro de los problemas del modelo en cascada es que requiere de un análisis
completo de los requerimientos para generar un documento completo antes de
iniciar las posteriores fases de diseño y desarrollo.

Una alternativa a estos modelos es utilizar las Historias de Usuario, como

mecanismo para ser mucho más ágil a la hora de captar los requisitos, así como
acercar la de nición nal de los mismos al último momento que se pueda, para
conseguir captar cualquier cambio en las ideas iniciales.

Según Mike Cohn, las Historias de Usuario describen la funcionalidad de algo que es
valioso para un usuario de un sistema o software.

Las Historias de Usuario se componen de tres elementos:

Una descripción escrita de la historia usada para la plani cación y como un

recordatorio.
Conversaciones sobre la necesidad de la historia que sirven para profundizar en
los detalles de la misma
Elementos de prueba que permiten determinar cuando las tareas que va a cubrir la
historia está completa.

Así una historia debe permitir conocer la base de las necesidades del usuario, así
como los detalles que después permitan jar la batería de pruebas  para poder
determinar si un desarrollo es correcto o no.

Inicialmente se jaba que esas historias de usuario se escribieran en unas tarjetas en

vez de en una libreta, lo que hizo que Ron Je ries lo llamara CCC Card, Conversation,
Con rmation (Tarjeta, Conversación y Con rmación). Así la tarjeta almacenaba la
http://fernandollopis.dlsi.ua.es/?p=39 2/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

historia del usuario, y a través de la Conversación y la con rmación. Hay autores que
a rman que las tarjetas son la mejor forma de almacenar las Historias de Usuario.

Otro de los aspectos fundamentales es que la historia de usuario debe estar

expresada en un lenguaje  que el usuario pueda entender y que re eja una
descripción sintetizada de lo que el usuario desea.

La descripción puede ser libre, aunque es generalmente el modelo propuesto por

Mike Cohn es el aceptado.  En él que se indican tres cosas, ¿Qué tipo de usuario es el
que solicita? ¿Qué se quiere? ¿Por qué se quiere?

Un ejemplo de Historia de Usuario podría ser:

“Como responsable de almacén quiero conocer cuando se alcanza el stock mínimo

para poder realizar más órdenes de compra.”

Atributos de las historias de usuario

Las Historias de Usuario son peticiones muy sencillas y claras que de nen 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

http://fernandollopis.dlsi.ua.es/?p=39 3/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

Small
Testable

A.        Independendientes (Independent)

Es razonable evitar la existencia entre dependencias entre las historias, es decir

historias que para estar nalizadas dependen de la nalización de otras. Esto añade
un punto más de complejidad a la plani cación de realización de tareas, obligando a
estar muy pendiente de estar interrelaciones y de nir una priorización en la
realización de las mismas.

Imaginemos las Historias de Usuario a de nir 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:

http://fernandollopis.dlsi.ua.es/?p=39 4/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

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 especi que 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
http://fernandollopis.dlsi.ua.es/?p=39 5/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

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 de nen en base a peticiones del usuario, no obstante
cabe la posibilidad de de nir 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.

http://fernandollopis.dlsi.ua.es/?p=39 6/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

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 plani car 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

1. 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 con anza
al cliente, y en segundo lugar abordar con el su ciente conocimiento los
desarrollos a realizar.
2. 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 con anza lo su cientemente 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.
3. 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)

http://fernandollopis.dlsi.ua.es/?p=39 7/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

El concepto pequeña es muy relativo, pero entendemos como que la Historia de

Usuario debe tener una duración que la haga lo su ciente 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 in erno la plani cación y la
integración de todas en el proyecto nal.

Es razonable que el equipo de desarrollo de na 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 pre eren
de nir 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 di cultad 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 de nir historias del tipo:

Como jefe de ventas quiero poder dar de alta un producto para venta
Como jefe de ventas quiero poder modi car 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.

http://fernandollopis.dlsi.ua.es/?p=39 8/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

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 modi car 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 de nir
claramente una batería de pruebas que pueda ser realizada para veri car 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 de nición de esas baterías de
prueba. No obstante se pueden de nir 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.

http://fernandollopis.dlsi.ua.es/?p=39 9/10
18/10/2018 Scrum. Historias de Usuario – Ingeniería Ágil

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 re ejen 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 especi cados, 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.

Fernando Llopis / 06/10/2016 / Uncategorized

Ingeniería Ágil / Proudly powered by WordPress

http://fernandollopis.dlsi.ua.es/?p=39 10/10