Leffingwell, LLC.

Introducción a una historia de

usuario

Por Dean
Leffingwell con
Pete Behrens

Resumen:
En este documento técnico, proporcionamos una descripción general sobre la derivación y aplicación
de historias de usuario, que son el mecanismo ágil principal que lleva los requisitos del cliente a través
del flujo de valor del desarrollo de software ágil. A su vez, las historias de usuario son un elemento
crítico del modelo de información de requisitos ajustables y escalables para empresas ágiles y el
panorama general de la agilidad empresarial, los cuales se pueden encontrar en el
blog.http://scalingsoftwareagility.wordpress.com/. Este documento se extrajo del próximo libro Agile
Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise, programado
para su publicación en 2010. Un agradecimiento especial a Jennifer Fawcett y Don Widrig por sus
contribuciones también.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
Contenido
Introducción3 ..........................................................................................................................................
Usuario Descripción general de la historia3 ........................................................................................
Las historias de usuario ayudan a tender puentes entre el desarrollador y la comunicación con el
cliente Gap4 ........................................................................................................................................
Las historias de usuario son No Requisitos4 .......................................................................................
Usuario Formulario de historia 5 ............................................................................................................
Tarjeta, Conversación y Confirmación5 ..............................................................................................
Usuario Story Voice5 ...........................................................................................................................
Usuario Detalle de la historia6 ............................................................................................................
Historia del usuario Criterios de aceptación6 .....................................................................................
INVERTIR en el bien Historias de usuarios7 ............................................................................................
Independiente7 ...................................................................................................................................
Negociable... y Negociado8 .................................................................................................................
Valioso8 ...............................................................................................................................................
Estimado9 ...........................................................................................................................................
Pequeño9 ............................................................................................................................................
Comprobable11...................................................................................................................................
Terrible Historias de usuarios11 .............................................................................................................
Picos14 ....................................................................................................................................................
Guias para Picos14 ..............................................................................................................................
Modelado de historias con Fichas15 .......................................................................................................
Resumen16 .............................................................................................................................................

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
Introducción a una historia de usuario
Han estado en una gran fiesta de idiomas y se han echado a perder.
- Moth to Costard, Love's Labor's Lost, Acto 5, escena 1, William Shakespeare

Introducción
En el desarrollo ágil, la historia del usuario es un sustituto ligero y más ágil de lo que ha sido nuestro
medio tradicional para especificar los requisitos de software: especificaciones de requisitos de software,
especificaciones de casos de uso y similares. De hecho, se puede argumentar que la historia del usuario es
el artefacto más importante en el desarrollo ágil, porque es el contenedor que principalmente lleva el flujo
de valor al usuario, y el desarrollo ágil tiene que ver con la entrega rápida de valor.
La historia del usuario también sirve como metáfora de todo nuestro enfoque de entrega de valor
incremental, es decir:
Defina una historia de valor para el usuario valiosa: impleméntela y pruébela en una breve iteración -
demostrar y/o envíelo al usuario: recopile comentarios, aprenda y repita para siempre.
He hablado brevemente de las historias de los usuarios en el contexto de mis documentos técnicos más
amplios, Un modelo de información de requisitos ajustables y escalable para empresas ágiles y El
panorama general de la agilidad empresarial1, donde, junto con los temas, las epopeyas y las
características, son los principales artefactos de requisitos que se utilizan por los equipos ágiles.
En este documento técnico, describiremos la historia del usuario con más detalle, porque es aquí donde
encontraremos una de las prácticas ágiles clave que nos ayudan a alinear nuestra solución directamente
con las necesidades específicas del usuario y, al mismo tiempo, ayudan a asegurar la calidad. .

Descripción general de la historia de usuario

En los documentos técnicos a los que se hace referencia y la serie de blogs relacionados, he destacado
muchas de las contribuciones del modelo Scrum a las prácticas empresariales ágiles, destacando, por
ejemplo, la definición del rol del propietario del producto, que es parte integral de nuestras prácticas de
requisitos. Pero es a XP a quien le debemos la invención de la historia del usuario, y son los defensores
de XP los que han desarrollado la amplitud y profundidad de este artefacto. Sin embargo, esto es menos
una "bifurcación metodológica en el camino" de lo que podría parecer, ya que las historias de usuario
ahora se enseñan de forma rutinaria dentro de las construcciones de la capacitación de Scrum como una
herramienta para construir la acumulación de productos y definir el contenido de Sprint. Quizás
tengamos que agradecer a Mike Cohn por gran parte de esta integración, ya que ha desarrollado historias
de usuarios extensamente en su libro User Stories Applied [Cohn 2004],
Para nuestros propósitos, definiremos una historia de usuario simplemente como:
Una historia de usuario es una breve declaración de intenciones que describe algo que el sistema debe hacer por
el usuario.
En XP, las historias de usuario a menudo las escribe el cliente, integrando así al cliente directamente en
el proceso de desarrollo. En Scrum, el propietario del producto a menudo escribe las historias de los
usuarios, con aportes de los clientes, las partes interesadas y el equipo. Sin embargo, en la práctica,
cualquier miembro del equipo con suficiente conocimiento del dominio puede escribir historias de
usuario, pero depende del propietario del producto aceptar y priorizar estas historias potenciales en la

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
cartera de pedidos del producto.

1
www.scalingsoftwareagility.wordpress.com

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
Las historias de usuario son una herramienta para definir el comportamiento de un sistema de una manera
que sea comprensible tanto para los desarrolladores como para los usuarios. Las historias de usuario
centran el trabajo en el valor definido por el usuario en lugar de en una estructura funcional de desglose,
que es la forma en que tradicionalmente se ha asignado el trabajo. Proporcionan un enfoque ligero y
eficaz para gestionar los requisitos de un sistema.
Una historia de usuario captura una breve declaración de función en una tarjeta de índice, o quizás con una
herramienta en línea.
Ejemplos:
Inicie sesión en mi portal web de
monitoreo de energía. Vea mi uso diario de
energía.
Verifique
Los detalles mi tarifa actual
del comportamiento delde facturación
sistema de electricidad
no aparecen en la declaración breve, y se dejan para que se
desarrollen más adelante a través de conversaciones y criterios de aceptación entre el equipo y el
propietario del producto.

Las historias de usuarios ayudan a cerrar la brecha de comunicación entre desarrolladores y

clientes
En el desarrollo ágil, el trabajo del desarrollador es hablar el idioma del usuario, no el trabajo del usuario
hablar el idioma de la tecnología. La comunicación eficaz es la clave y necesitamos un lenguaje común.
La historia del usuario proporciona el lenguaje común para generar entendimiento entre el usuario y el
equipo técnico.
Bill Wake, uno de los creadores de XP, lo describe de esta manera2:
Un lenguaje pidgin es un lenguaje simplificado, generalmente utilizado para el comercio, que permite a
las personas que no pueden comunicarse en su idioma nativo trabajar juntas. Las historias de usuario
actúan así. No esperamos que los clientes o usuarios vean el sistema de la misma manera que lo hacen
los programadores; las historias actúan como un lenguaje pidgin en el que ambas partes pueden
ponerse de acuerdo lo suficiente como para trabajar juntas de manera efectiva.
Con las historias de usuario, no tenemos que entender el idioma de los demás con el grado de competencia
necesario para elaborar un soneto; ¡Solo necesitamos entendernos lo suficiente como para saber cuándo
hemos llegado a un acuerdo adecuado!

Las historias de usuario no son requisitos

Si bien las historias de usuario hacen la mayor parte del trabajo realizado anteriormente por las
especificaciones de requisitos de software, casos de uso y similares, son materialmente diferentes en
una serie de formas sutiles pero críticas.
• No son especificaciones de requisitos detalladas (algo que un sistema debe hacer) sino
más bien expresiones de intención negociables (necesita hacer algo como esto)
• Son breves y fáciles de leer, comprensibles para los desarrolladores, las partes interesadas y los
usuarios.
• Representan pequeños incrementos de funcionalidad valiosa, que se pueden
desarrollar en un período de días a semanas.
• Son relativamente fáciles de estimar, por lo que el esfuerzo para implementar la
funcionalidad se puede determinar rápidamente.
• No se incluyen en documentos grandes y difíciles de manejar, sino que se organizan en
listas que se pueden organizar y reorganizar más fácilmente a medida que se descubre
nueva información.
• No se detallan al principio del proyecto, pero se elaboran justo a tiempo.
- evitando así la especificidad demasiado temprana, las demoras en el desarrollo, el
inventario de requisitos y una declaración de la solución demasiado restringida
• Necesitan poco o ningún mantenimiento y se pueden desechar de forma segura después de la

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
 implementación3

2
http://xp123.com/xplor/xp0308/index.shtml
3
Sujeto al desarrollo y persistencia de pruebas de aceptación, que definen el comportamiento del sistema con detalle comprobable
por regresión.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
 • Las historias de usuario y el código que se crea rápidamente a partir de
entonces sirven como entradas para la documentación, que luego también se
desarrolla de forma incremental.

Formulario de historia de usuario

Tarjeta, conversación y confirmación
Ron Jeffries, otro de los creadores de XP, describió lo que se ha convertido en nuestra forma favorita
de pensar sobre las historias de los usuarios. Usó la aliteración, la tarjeta, la conversación y la
confirmación4 para describir los tres elementos de una historia de usuario. Dónde:
Tarjeta representa 2-3 oraciones que se utilizan para describir la intención de la historia. La tarjeta
sirve como un token memorable, que resume la intención y representa un requisito más detallado,
cuyos detalles quedan por determinar.
Nota: En XP y ágil, las historias a menudo se escriben
manualmente en fichas físicas. Más típicamente en la
empresa, el elemento "tarjeta" se captura como texto y
archivos adjuntos en una hoja de cálculo o herramientas de
gestión de proyectos ágiles, pero los equipos a menudo
todavía usan tarjetas para la planificación temprana y la
lluvia de
Conversacion ideas, como
representa una veremos
discusiónmás adelante.
entre el equipo, el cliente, el
propietario del producto y otras partes interesadas, que es necesaria
para determinar el comportamiento más detallado necesario para
implementar la intención. En otras palabras, la tarjeta también
representa una "promesa de conversación" sobre la intención.
Confirmación representa la prueba de aceptación, que es la
forma en que el cliente o propietario del producto confirmará que
la historia se ha implementado a su satisfacción. En otras
palabras, la Confirmación representa las condiciones de
satisfacción que se aplicarán para determinar si la historia cumple
o no con la intención, así como con los requisitos más detallados.
Con esta simple aliteración, tenemos una lección objetiva sobre cómo se logra la calidad en ágil
durante, en lugar de después, el desarrollo de código real. Lo hacemos simplemente asegurándonos de
que cada nueva historia de usuario sea
a) se discute y perfecciona con el detalle necesario, y b) se prueba a satisfacción de las partes
interesadas clave.

Voz de la historia de usuario

En los últimos años, se ha aplicado una nueva forma estandarizada que fortalece significativamente la
construcción de la historia del usuario. El formulario es el siguiente:
Como <función> puedo <actividad> para que <valor
comercial> donde:
• Rol - representa quién está realizando la acción o quizás alguien que está recibiendo el
valor de la actividad. Incluso puede ser otro sistema, si eso es lo que está iniciando la
actividad.
• Actividad - representa la acción que debe realizar el sistema.
• Valor de negocio - representa el valor para el negocio.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
4
http://xprogramming.com/xpmag/expcardconversationconfirmation/

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
A esto lo llamamos la forma de expresión de la historia de usuario de “voz del usuario” y lo
consideramos una construcción extremadamente útil5 porque abarca el espacio del problema (<valor
comercial> entregado) y el espacio de la solución (<actividad> que el usuario realiza con el sistema).
También proporciona una perspectiva de usuario primero (<función>) al equipo, lo que los mantiene
enfocados en el valor comercial y en la resolución de problemas reales para personas reales.
Esta forma de historia de usuario mejora en gran medida la comprensión de por qué y cómo los
desarrolladores necesitan implementar un sistema que realmente satisfaga las necesidades de los
usuarios.
Por ejemplo, un usuario de un sistema de gestión de energía en el hogar podría querer: 6
Como consumidor, (<función>) Quiero poder ver mi uso diario de energía. (<lo que hago con el sistema>)
para que pueda comenzar a comprender cómo reducir mis costos con el tiempo (<valor comercial que
recibo>).
Cada elemento proporciona un contexto expansivo importante. El rol permite una segmentación de la
funcionalidad del producto y, por lo general, extrae otras necesidades basadas en el rol y el contexto de la
actividad. Por lo general, la actividad representa el "requisito" que necesita el rol. Y el valor comunica
por qué se necesita la actividad, lo que a menudo puede llevar al equipo a encontrar posibles actividades
alternativas que podrían proporcionar el mismo valor por menos esfuerzo.

Detalle de la historia de usuario

Los detalles de las historias de usuario se transmiten principalmente a través de una conversación entre el
propietario del producto y el equipo, lo que mantiene al equipo involucrado desde el principio. Sin
embargo, si se necesitan más detalles sobre la historia, se pueden proporcionar en forma de un archivo
adjunto (maqueta, hoja de cálculo, algoritmo o lo que sea), que se adjunta a la historia del usuario. En ese
caso, la historia del usuario sirve como la "ficha" que también lleva el comportamiento más específico al
equipo. Los detalles adicionales de la historia del usuario deben recopilarse a lo largo del tiempo (justo a
tiempo) a través de discusiones y colaboración con el equipo y otras partes interesadas antes y durante el
desarrollo.

Criterios de aceptación de la historia de usuario

Además de la declaración de la historia del usuario, se pueden guardar notas adicionales, suposiciones y
criterios de aceptación con una historia de usuario. Es probable que muchas discusiones sobre una
historia entre el equipo y los clientes tengan lugar antes y durante el tiempo en que la historia está
comprometida con el código. Los flujos alternativos en la actividad, los límites de aceptación y otras
aclaraciones deben capturarse junto con la historia. Muchos de estos se pueden convertir en casos de
prueba de aceptación u otros casos de prueba funcionales para la historia.
Por ejemplo,
Como consumidor, quiero poder ver mi uso diario de energía para poder comenzar a comprender cómo
reducir mis costos con el tiempo.
Criterios de aceptación:
• Leer los datos del medidor DecaWatt cada 10 segundos y mostrarlos en el portal en
incrementos de 15 minutos y mostrarlos en la pantalla del hogar cada lectura
• Lea los medidores de kilovatios para ver los nuevos datos disponibles y visualícelos en el
portal cada hora y en la pantalla del hogar después de cada lectura.
• No hay tendencias de varios días por ahora (otra historia).
Etc ...
Los Criterios de aceptación no son pruebas funcionales o unitarias, sino que son las condiciones de
satisfacción que se colocan en el sistema. Las pruebas funcionales y unitarias son mucho más profundas
en la prueba de todos los flujos funcionales, flujos de excepción, condiciones de límite y funcionalidad
relacionada asociada con la historia.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
5
Mientras buscaba el origen de esta forma, Leffingwell recibió la siguiente nota de Mike Cohn: “Comenzó con un equipo en
Connextra en Londres y fue mencionado en XP2003. Comencé a usarlo entonces y escribí sobre él en mi libro de 2004, User
Stories Applied."
6
Gracias a Jennifer Fawcett de Tendril Networks por proporcionar estos ejemplos

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
INVIERTA en buenas historias de usuarios
Los equipos ágiles dedican una cantidad significativa de tiempo (quizás la mitad o más) a descubrir,
elaborar y comprender las historias de los usuarios y redactar pruebas de aceptación para ellos. Así debe
ser, porque representa el hecho de que:
Escribir el código para un objetivo entendido no es necesariamente la parte más difícil del desarrollo de
software, sino comprender cuál es el objetivo real del código.
Por tanto, invertir en buenas historias de usuario, aunque sea en el último momento responsable, es un
esfuerzo digno para el equipo. Bill Wake, acuñó el acrónimo INVEST7, para describir los atributos de
una buena historia de usuario.

Independien
te
norteegoí
sta
Valios
o
Estima
do
Pequeñ
o
Comprobable
El modelo INVEST es bastante ubicuo y muchos equipos ágiles evalúan sus historias con respecto a
estos atributos. Aquí está nuestra opinión sobre el valor de la INVERSIÓN del equipo.

Independiente
Independencia significa que una historia puede desarrollarse, probarse y potencialmente incluso
entregarse por sí sola. Por lo tanto, también se puede valorar de forma independiente.
Muchas historias tendrán algunas dependencias secuenciales naturales a medida que se desarrolle la
funcionalidad del producto y, sin embargo, cada pieza puede ofrecer valor de forma independiente. Por
ejemplo, un producto puede mostrar un solo registro, luego una lista, luego ordenar la lista, filtrar la lista,
preparar una lista de varias páginas, exportar la lista, editar elementos en la lista, etc.
Muchos de estos elementos tienen dependencias secuenciales, pero cada elemento proporciona un
valor independiente y el producto puede enviarse potencialmente a través de cualquier punto de
parada del desarrollo.
Sin embargo, muchas dependencias no valoradas, ya sean técnicas o funcionales, también tienden a
encontrar su camino en los atrasos y es necesario encontrarlas y eliminarlas. Por ejemplo, una
dependencia funcional no valorada podría ser:
Como administrador, puedo establecer las reglas de seguridad de contraseñas del consumidor para
que los usuarios deban crear y retener contraseñas seguras, manteniendo seguro el sistema.

Como consumidor, debo seguir las reglas de seguridad de contraseñas establecidas por el
administrador para poder mantener una alta seguridad en mi cuenta.

En este ejemplo, la historia del consumidor depende de la historia del administrador. La historia del
administrador solo se puede probar para establecer, borrar y preservar la política; pero no se puede
comprobar si se aplica al consumidor. Además, completar la historia del administrador no deja el
producto en un estado potencialmente apto para el envío.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
- por lo tanto, no valioso de forma independiente.
Al reconsiderar las historias (y el diseño del sistema) podemos eliminar la dependencia dividiendo las
historias de una manera diferente, en este caso a través de los tipos de políticas de seguridad aplicadas
y combinando la configuración con la aplicación en cada historia:
Como administrador, puedo establecer el período de caducidad de la contraseña para que los
usuarios se vean obligados a cambiar sus contraseñas periódicamente.

7
Bill Wake. http://xp123.com/xplor/xp0308/index.shtml

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
 Como administrador, puedo establecer las características de seguridad de la contraseña para que
los usuarios deban crear contraseñas difíciles de piratear.
Ahora, cada historia puede valerse por sí misma y puede desarrollarse, probarse y presentarse de forma
independiente.

Negociable ... y Negociado

A diferencia de los requisitos tradicionales, una historia de usuario no es un contrato para una
funcionalidad específica, sino más bien un marcador de posición para que los requisitos se discutan,
desarrollen, prueben y acepten. Este proceso de negociación entre la empresa y el equipo reconoce la
legitimidad y primacía de los insumos empresariales, pero permite el descubrimiento a través de la
colaboración y la retroalimentación.
En nuestras organizaciones anteriores, en silos, generalmente se requerían requisitos escritos para
facilitar el ancho de banda de comunicación limitado entre departamentos y para servir como registro de
acuerdos pasados. Sin embargo, Agile se basa en el concepto de que un enfoque basado en equipos es
más eficaz para resolver problemas en un entorno colaborativo dinámico. Una historia de usuario es en
tiempo real y está estructurada para aprovechar este enfoque de colaboración y comunicación directa y
eficaz.
Finalmente, la negociabilidad de las historias de usuario ayuda a los equipos a lograr la previsibilidad. La
falta de requisitos demasiado limitados y demasiado detallados mejora la capacidad de los equipos y las
empresas para hacer concesiones entre la funcionalidad y las fechas de entrega. Debido a que cada
historia tiene flexibilidad, el equipo tiene más flexibilidad para cumplir con los objetivos de lanzamiento,
lo que aumenta la confiabilidad y fomenta la confianza.

Valioso
El objetivo de un equipo ágil es simple: ofrecer el máximo valor dadas las limitaciones de tiempo y
recursos existentes. Por lo tanto, el valor es el atributo más importante en el modelo INVEST y cada
historia de usuario debe proporcionar algún valor al usuario, cliente o parte interesada del producto. Los
trabajos pendientes se priorizan por valor y las empresas tienen éxito o fracasan en función del valor que
los equipos pueden ofrecer.
Un desafío típico que enfrentan los equipos es aprender a escribir historias de usuarios pequeñas e
incrementales que puedan generar valor de manera efectiva. Los enfoques tradicionales nos han
arraigado para crear estructuras funcionales de descomposición basadas en componentes técnicos. Este
enfoque de capas técnicas para la creación de software retrasa la entrega de valor hasta que todas las
capas se unen después de múltiples iteraciones. Wake8 ofrece su perspectiva de capas verticales, en
lugar de técnicas.
Piense en una historia completa como un pastel de varias capas, por ejemplo, una capa de red,
una capa de persistencia, una capa lógica y una capa de presentación. Cuando dividimos una
historia [horizontalmente], solo servimos una parte de ese pastel. Queremos darle al cliente la
esencia de todo el pastel, y la mejor manera es cortar verticalmente las capas. Los
desarrolladores a menudo tienen la inclinación de trabajar solo en una capa a la vez (y hacerlo
"bien"); pero una capa de base de datos completa (por ejemplo) tiene poco valor para el cliente
si no hay una capa de presentación.
La creación de historias valiosas requiere que reorientemos nuestras estructuras funcionales de ruptura de
un enfoque horizontal a uno vertical. Creamos historias que atraviesan la arquitectura para que podamos
presentar valor al usuario y buscar su retroalimentación lo antes y con la mayor frecuencia posible.
Si bien normalmente el valor se centra en la interacción del usuario con el sistema, a veces el valor se
centra más apropiadamente en un representante del cliente o una parte interesada clave. Por ejemplo,
quizás un director de marketing solicita una tasa de clics más alta en los anuncios presentados en el sitio
web. Si bien la historia podría escribirse desde la perspectiva del usuario final:
Como consumidor, puedo ver otros programas de precios de energía que me atraen para poder
inscribirme en un programa que se adapte mejor a mi estilo de vida.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
... para proporcionar una perspectiva más clara sobre el valor real, sería más apropiado redactarlo
desde la perspectiva del director de marketing:

8
ibídem

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
 Como director de marketing de servicios públicos, puedo presentar a los usuarios nuevos programas
de precios para que sea más probable que sigan comprándome energía.
Otro desafío al que se enfrentan los equipos es articular el valor de las historias técnicas como la
refactorización de código, las actualizaciones de componentes, etc. Por ejemplo, ¿cómo determinaría
el propietario del producto el valor de:
Refactorizar el registro de errores sistema.

Articular el valor de una solución técnica como una historia de usuario ayudará a comunicar a la
empresa su importancia relativa. Por ejemplo:
Como consumidor, puedo recibir un mensaje de error claro y coherente en cualquier parte del
producto para saber cómo abordar el problema. O

Como miembro de soporte técnico, quiero que el usuario reciba un mensaje coherente y claro en
cualquier lugar de la aplicación para que pueda solucionar el problema sin llamar al soporte.

En estos últimos ejemplos, el valor es claro para el usuario, para el propietario del producto, las partes
interesadas, y para el equipo.

Estimable
Una buena historia de usuario es estimable. Si bien una historia de cualquier tamaño puede estar en la
lista de trabajos pendientes, para que se desarrolle y pruebe en una iteración, el equipo debe poder
proporcionar una estimación aproximada de su complejidad y la cantidad de trabajo requerido para
completarla. La inversión mínima en la estimación es determinar si se puede completar en una sola
iteración. La precisión adicional de la estimación aumentará la previsibilidad del equipo.
Si el equipo no puede estimar la historia de un usuario, generalmente indica que la historia es demasiado
grande o incierta. Si es demasiado grande para estimarlo, debe dividirse en historias más pequeñas. Si la
historia es demasiado incierta para estimar, entonces se puede usar una historia de picos técnicos o
funcionales para reducir la incertidumbre, de modo que resulten una o más historias de usuarios
estimables. (Cada uno de estos temas se analiza con más detalle en las siguientes secciones).
Uno de los principales beneficios de estimar historias de usuarios no es simplemente derivar un tamaño
preciso, sino más bien extraer cualquier suposición oculta, criterios de aceptación faltantes y aclarar la
comprensión compartida del equipo de la historia. Por lo tanto, la conversación en torno al proceso de
estimación es tan (o más) importante que la estimación real. La capacidad de estimar una historia de
usuario está muy influenciada por el tamaño de la historia, como veremos a continuación.

Pequeña
Las historias de usuario deben ser lo suficientemente pequeñas como para poder completarse en una
iteración; de lo contrario, no pueden proporcionar ningún valor o considerarse realizadas en ese
momento. Sin embargo, historias de usuarios aún más pequeñas brindan más agilidad y productividad.
Hay dos razones principales para esto: mayor rendimiento y menor complejidad.
Mayor rendimiento
A partir de la teoría de las colas, sabemos que los lotes más pequeños pasan por un sistema más
rápido. Este es uno de los principios primarios del flujo magro y está reflejado en la ley de Little:

En un sistema estable (donde el rendimiento, la cantidad de trabajo que se puede hacer en una unidad de
tiempo, es constante), tenemos que disminuir el trabajo en proceso (la cantidad de cosas en las que
estamos trabajando) para disminuir el tiempo de ciclo (el tiempo transcurrido entre el inicio y el final del
proceso). En nuestro caso, eso significa que menos historias más pequeñas en proceso saldrán más

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
rápido.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
Además, cuando un sistema se carga al máximo de su capacidad, puede volverse inestable y el problema
se agrava. En sistemas muy cargados, los lotes más grandes se mueven desproporcionadamente más lento
(el rendimiento disminuye) a través del sistema. (Piense en un sistema de carreteras en la hora pico. Una
motocicleta tiene un rendimiento mucho mayor que los automóviles y camiones. Hay más espacio para
maniobrar cosas más pequeñas a través de un sistema cargado). Porque los equipos de desarrollo
generalmente están completamente asignados a la capacidad o por encima de ella (80 -120%), se
encuentran en la categoría de carreteras de “hora punta”.
Cuando la capacidad alcanza el 80% aproximadamente, los objetos más grandes aumentan el tiempo de
ciclo (ralentizan) mucho más que los objetos más pequeños. Peor aún, la variación en el tiempo del
ciclo aumenta, lo que significa que se vuelve más difícil predecir cuándo un lote realmente podría salir
del sistema, como se puede ver en la Figura 1 a continuación9. A su vez, esta menor previsibilidad

causa estragos en los horarios, los compromisos y la credibilidad del equipo.

Figura 1 Los lotes grandes tienen menor rendimiento y mayor variabilidad en el tiempo de ciclo.
Complejidad disminuida
Las historias más pequeñas no solo pasan más rápido debido a su tamaño proporcional y crudo, sino que
también lo hacen más rápido debido a su menor complejidad, y la complejidad tiene una relación no
lineal con el tamaño. Esto se ve más fácilmente en las pruebas donde las permutaciones de las pruebas
necesarias para validar la funcionalidad aumentan a un ritmo exponencial con la complejidad de la
función en sí. Esto se correlaciona con los consejos que recibimos sobre el desarrollo de código limpio,
como señala Robert Martin [Martin 2009] sobre sus reglas para escribir funciones de software:
Regla 1: Haz una cosa
Regla 2: Mantenlos
pequeños
Regla 3: hazlos más pequeños que eso
Esta es una de las razones principales por las que la secuencia de estimación de Fibonacci (es decir, 1,
2, 3, 5, 8, 13, 21…) es tan eficaz en la estimación de historias de usuarios: la estimación del esfuerzo
crece de forma no lineal al aumentar el tamaño de la historia.
Sobre la relación de tamaño e independencia
Surge una pregunta justa en cuanto a la relación entre tamaño e independencia, ya que parece lógico que
las historias más pequeñas aumenten el número de dependencias. Sin embargo, las historias más
pequeñas, incluso con una mayor dependencia, ofrecen un rendimiento de mayor valor y proporcionan
comentarios de los usuarios más rápidos que las historias más grandes. Entonces, el agilista siempre se
inclina por historias más pequeñas y luego las hace aún más pequeñas.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
9
Fuente: [Poppendieck 2007].

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
Comprobable
En agile correctamente hecho, todo el código es código probado, por lo que se deduce que las historias
deben ser comprobables. Si una historia no parece ser comprobable, es probable que la historia esté mal
formada, sea demasiado compleja o tal vez dependa de otras historias del atraso.
Para asegurarse de que las historias no entren en una iteración si no pueden salir, muchos equipos ágiles
de hoy adoptan un enfoque de escribir la prueba primero. Esto comenzó en la comunidad de XP
utilizando Test Driven Development, una práctica de escribir pruebas unitarias automatizadas antes de
escribir el código para aprobar la prueba.
Desde entonces, esta filosofía de enfoque se está aplicando al desarrollo de los criterios de aceptación
de la historia y las pruebas funcionales necesarias antes de codificar la historia en sí. Si un equipo
realmente sabe cómo probarlo, es probable que también sepa cómo codificarlo.
Para garantizar la capacidad de prueba, las historias de usuario comparten algunos errores comunes de
capacidad de prueba con requisitos vagos. Palabras como rápido, administrar, agradable, limpio, etc. son
fáciles de escribir, pero difíciles de probar porque significan cosas diferentes para diferentes personas y,
por lo tanto, deben evitarse. Y si bien estas palabras brindan negociabilidad, proporcionar algunos límites
claros y objetivos ayudará al equipo y a la empresa a compartir las expectativas del resultado y evitar
grandes sorpresas.

División de historias de usuarios

Una historia de usuario generalmente comienza como una característica o una
epopeya: un concepto amplio y vago de algo que queremos hacer por un
usuario. A menudo encontramos estas grandes historias vagas durante nuestro
proceso de descubrimiento y las capturamos en el trabajo pendiente. Sin
embargo, estas son historias compuestas, como se muestra a la derecha, y
generalmente son demasiado grandes para ser implementadas dentro de una
iteración. Para preparar el trabajo para las iteraciones, un equipo debe
dividirlas en historias más pequeñas.
No existe una rutina establecida para dividir las historias de los usuarios en
fragmentos del tamaño de una iteración, aparte de la guía general para hacer que
cada historia proporcione una porción vertical, una parte del valor del usuario, a
través del sistema. Sin embargo, con base en un trabajo reciente de Richard
Lawrence, recomendamos aplicar una selección adecuada de diez patrones
comunes para dividir una historia de usuario, como indica la Tabla 110:

© 2009, Leffingwell, LLC. Reservados todos

los derechos.
10
Adaptado de Richard Lawrence, http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/.

© 2009, Leffingwell, LLC. Reservados todos

los derechos.