10 estrategias útiles para descomponer historias de usuario

grandes
Si en algún momento nos encontramos frente al reto de que nuestro equipo Scrum
cuente siempre con un Backlog adecuado para atender los items especificados, es
necesario que todos puedan contribuir en su mantenimiento y actualización. A
continuación se encuentra la versión traducida al castellano del artículo “10 useful
strategies for breaking down large User Stories (and a cheatsheet)” escrito por
Christiaan Verwijs.

Los equipos que han llegado a dominar Scrum saben que la clave del éxito radica
disponer de un Product Backlog que se encuentre siempre disponible para su uso, con
un refinado incremental y en el cual el trabajo este desglosado. Los equipos prefieren
Sprint Backlogs con varios ítems pequeños (funcionales) en lugar de solamente
algunos ítems grandes. Los ítems pequeños mejoran el flujo y reducen el riesgo de
que el Sprint falle. En este artículo, explicaré por qué es importante la descomposición
del trabajo y por qué debería ser hecho de manera transversal a la funcionalidad, en
lugar de considerar características técnicos. A continuación daré a conocer ofreceré 10
estrategias útiles que los equipos Scrum experimentados usan para descomponer el
trabajo.

Para el resto de este artículo, usaré “Historias de Usuario” para indicar ítems
funcionales en el Product Backlog. Hay que tener en cuenta que las “Historias de
usuario” están destinadas a ayudar para que los equipos piensen en términos de
funcionalidad, en lugar de técnicos. Los términos técnicos no son requeridos.

Por qué y cuándo descomponer los ítems

El desarrollo de software es ciertamente impredecible. Algunas “Historias de Usuario”

del Backlog requerirán más esfuerzo de lo esperado, mientras que otros ítems
requerirán menos. Por lo tanto, si el trabajo para un Sprint contiene solo algunos ítems
grandes, el impacto de una inadecuada estimación del trabajo, o incluso de un solo
item tendrá un impacto profundo en el Sprint. Y dado que los ítems más grandes
tienden a ser más difíciles de estimar y comprender, la posibilidad de que el Sprint falle
se aumenta.

Los equipos experimentados de Scrum dedican tiempo y esfuerzo a desglosar grandes

Historias de Usuario en unas más pequeñas. Aunque a veces lo hacen durante la
planificación de un nuevo Sprint, han aprendido que este proceso de “refinamiento”
debe ser continuo para hacer que los Sprints, y en particular su planificación, sean
más fluidas. Entonces, cuando un Sprint está en marcha, el equipo también pasa
tiempo analizando Historias de Usuario para el próximo Sprint, y quizás incluso para el
Sprint posterior. Pero esto se realiza de la manera “just-in-time”, de manera que el
equipo pasa cada vez menos tiempo en los Sprints lejanos.

Este proceso de descomponer el trabajo mejora la comprensión compartida, aumenta

la precisión de la estimación y facilita al Product Owner en la priorización del trabajo.
Pero realizar esta tarea de buena manera no es fácil, y se necesita práctica para

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 hacerlo “sobre la marcha”. Afortunadamente, la comunidad ágil ha ideado una serie de
estrategias útiles para desglosar el trabajo en trozos más pequeños.

Por qué una descomposición vertical es superior a una horizontal

En términos generales, existen dos enfoques para dividir grandes Historias de

Usuarios. El primer enfoque se llama “descomposición horizontal” e implica desglosar
las historias por el tipo de trabajo que se necesita hacer, o las capas o componentes
que están involucrados. Es decir, el trabajo que se tiene que hacer para la UI, la base
de datos, algunos componentes, el front-end y las pruebas se dividen en ítems
técnicos en el Backlog. Esto no funciona bien en Scrum por varias razones:

 Los ítems individuales no dan como resultado un software funcional ni demostrable:

supongamos que un equipo trabaja en un proceso de pedido para una tienda en línea
en un Sprint. Si dividieran horizontalmente la Historia del Usuario, terminarían
trabajando en el diseño, la base de datos, el front-end y las pruebas. Aunque los
artículos son ciertamente más pequeños, no entregan software que funcione por sí
mismos. Después de todo, una pieza de funcionalidad no puede activarse cuando solo
se termina la interfaz de usuario, o cuando solo se modificó la base de datos. También
es una mala idea salir a producción sin suficientes pruebas. Por lo tanto, los ítems
individuales no dan como resultado un software funcional ni demostrable y, en
consecuencia con valor para el negocio. Solo la combinación de todo el trabajo genera
valor para el negocio. Pero si se genera valor cuando todas las tareas están
completas. Y esto a menudo es un problema, como explica a continuación;
 Incrementa los cuellos de botella, en lugar de reducirlos: la descomposición horizontal
a menudo va acompañada de un “pensamiento silo”. Cada uno de los miembros es
tomado de uno de los silos necesarios para el desarrollo de software. El “diseñador” se
encargará del diseño, el “administrador de base de datos” configurará la base de
datos, el “desarrollador” escribirá el código y el de “QA” hará las pruebas. Si los
miembros del equipo no son intercambiables (que a menudo es el caso cuando se
utiliza este enfoque), existe una buena posibilidad de que se produzcan cuellos de
botella. Si el “diseñador” no puede hacer su trabajo a tiempo, esto tendrá un impacto
en las tareas que siguen al diseño. Debido a que los miembros del equipo no pueden
ayudarse mutuamente, cada retraso, problema o interrupción afectará todo el Sprint;
 Las divisiones horizontales no se pueden priorizar: ¿cómo puede un Product Owner
priorizar un Backlog si este consta de sectores horizontales? Debido a que ninguno de
los elementos entrega valor comercial o software que funcione por sí solo, el Product
Owner no podrá priorizar el trabajo. También existe una buena posibilidad de que los
cortes sean bastante técnicos, lo que crea distancia y malentendidos entre el Product
Owner y el equipo;

Aunque un desglose horizontal de las historias de los usuarios dará como resultado
elementos más pequeños, limita severamente la capacidad de un equipo para entregar
software que funcione, evitar los cuellos de botella y priorizar el trabajo. Por lo tanto,
aumenta el riesgo de fallar el Sprint. Es una mala idea.

En Scrum, una descomposición vertical es más útil, en el que las Historias de Usuarios
se dividen en otras más pequeñas (en lugar de tareas técnicas). Si las historias de los
usuarios se desglosan verticalmente, se dividen de tal manera que los ítems más
pequeños aún resultan en software que funciona y son demostrables. La funcionalidad
no se dividirá en capas técnicas o tareas, sino en capas funcionales. Entonces, si la
historia del usuario es “Como cliente quiero pagar mi pedido, para obtener mis
productos”, se puede dividir en historias de usuarios más pequeños como las

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
siguientes “Como cliente quiero pagar por transferencia bancaria, para obtener mi
productos “o” Como cliente quiero pagar con tarjeta de crédito, para que pueda
obtener mis productos “.

Una metáfora nos permitirá aclarar aún más la diferencia. Imagina rebanar un pastel
con capas de crema, fruta y pastel. Si cortara la torta horizontalmente, cada invitado
solo obtendría una porción de pastel, crema o fruta. Estoy seguro de que sus invitados
habrían esperado algo más. Obtener solo una capa del pastel no les permite probar
todo el pastel. Un enfoque más amistoso es cortar el pastel en pedazos verticales,
cada una con un poco de pastel, crema y fruta:

Hay muchas estrategias disponibles para desglosar Historias de Usuarios grandes. He

recogido diez de los más útiles. Como podrás apreciar, estas estrategias no solo
ayudan a desglosar las Historias de Usuarios, sino que también ayudan a decidir qué
es importante y qué no. De esta forma, el Product Owner puede priorizar más
fácilmente el trabajo y tomar mejores decisiones respecto a lo que el equipo Scrum se
debería dedicar.

Estrategia 1: Descomponiendo el flujo de trabajo en pasos.

Si una historia de usuario involucra un flujo de trabajo de cualquier tipo, este

usualmente puede ser descompuesto en pasos individuales.

Ejemplo: Historia de usuario de un proceso de compra en una tienda web:

Como cliente,

quiero pagar los productos de mi carrito de compras,

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 para recibir los productos en mi casa.

Se podría identificar los siguientes pasos:

 Como cliente, quiero iniciar sesión con mi cuenta, de tal modo que no tengo que volver
a ingresar mi información personal cada vez;
 Como cliente, quiero revisar y confirmar mi pedido, para poder corregir los errores
antes de pagar;
 Como cliente, quiero pagar mi pedido con una transferencia bancaria, para poder
confirmar mi pedido;
 Como cliente quiero pagar mi pedido con tarjeta de crédito, para poder confirmar mi
pedido;
 Como cliente, quiero recibir un correo electrónico de confirmación de mi pedido, para
tener un comprobante de mi compra;

Al desglosar una gran Historia de Usuario como esta, hemos mejorado nuestra
comprensión de la funcionalidad y nuestra capacidad de estimación. También será
más fácil para un Product Owner priorizar el trabajo. Es posible que algunos pasos en
el flujo de trabajo no sean importantes en este momento y se puedan mover a futuros
Sprints. Tal vez el correo electrónico de confirmación del pedido se pueda hacer a
mano por el momento, o los clientes solo pueden pagar con tarjeta de crédito de
manera inicial. También podría estar bien solicitar a los clientes que vuelvan a ingresar
(temporalmente) su información personal para cada pedido. Sin duda, esto limitará la
funcionalidad de la tienda web, pero permite que un equipo Scrum revise (y tal vez
incluso implemente) la funcionalidad completa al final del Sprint, realiza pruebas y
utiliza el feedback para realizar los cambios necesarios.

Estrategia 2: Desglose por reglas de negocio

Las historias de usuario a menudo involucran de manera explícita o implícita reglas de

negocio.

Ejemplo: Proceso de pedido de una tienda online:

Como cliente,

quiero comprar los productos de mi carrito de compras,

para poder recibir mis productos en mí casa.

Se podría identificar las siguientes “reglas de negocio:

 Como propietario de una tienda, quiero rechazar pedidos inferiores a 10 dólares

porque no son rentables;
 Como propietario de una tienda, quiero rechazar clientes fuera de los EE. UU. Porque
los gastos de envío hacen que estas órdenes no sean rentables;
 Como propietario de la tienda, quiero reservar productos en el stock durante 48 horas,
para que otros clientes vean un stock realista;

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 Como propietario de la tienda, quiero cancelar automáticamente los pedidos para los
cuales no he recibido el pago en 48 horas, de modo que puedo volver a venderlos a
otros clientes;

Las reglas de negocio a menudo están implícitas, por lo que se necesitarán algunas
habilidades y destrezas analíticas para identificarlas. Puede ser útil emplear otra
estrategia (descrita en la estrategia Nro. 7); ¿cómo se probará la funcionalidad? A
menudo, los casos de prueba implican reglas de negocio importantes. Una vez que se
hayan identificado las reglas de negocio, de nuevo habrá mejorado nuestra
comprensión y capacidad de estimación. El Product Owner puede decidir que algunas
reglas comerciales no son importantes por el momento o pueden implementarse de
forma simplificada. Tal vez está bien por ahora devolver manualmente los productos
no pagados al inventario cuando no se ha recibido un pago dentro de las 48 horas, o
los pedidos se pueden cancelar manualmente. Aún más pragmáticamente, un mensaje
en el sitio explicando que “los pedidos no se envían fuera de los EE. UU.” O que “el
precio mínimo del pedido debe ser de al menos 10 dólares” puede ser suficiente por
ahora. Ahorrará tiempo y dinero necesarios para hacer cumplir esta regla comercial.

Estrategia 3: Desglose por un flujo feliz / infeliz

La funcionalidad a menudo implica un flujo feliz y uno o más flujos infelices. El flujo
feliz describe cómo se comporta la funcionalidad cuando todo va bien. Si hay
desviaciones, excepciones u otros problemas, se invocan flujos infelices.

Ejemplo: Iniciar sesión en un sitio web seguro:

Como cliente,

quiero iniciar sesión con mi cuenta,

para poder acceder a páginas seguras.

Podemos identificar un flujo feliz y varios flujos infelices potenciales:

 Como usuario, quiero iniciar sesión con mi cuenta, de modo que pueda acceder a
páginas seguras (feliz);
 Como usuario, quiero restablecer mi contraseña cuando falla mi inicio de sesión, por lo
que puedo intentar iniciar sesión de nuevo (infeliz);
 Como usuario, quiero la opción de registrar una nueva cuenta si no se conoce mi
nombre de usuario, de modo que puedo obtener acceso a páginas seguras (infeliz);
 Como propietario del sitio, quiero bloquear a los usuarios que inician sesión
incorrectamente tres veces seguidas, para poder proteger el sitio contra los piratas
informáticos (infelices);

Los flujos infelices describen excepciones. Al identificar los distintos flujos,

comprendemos más claramente la funcionalidad requerida. Un Product Owner puede
decidir más fácilmente lo que es importante en este momento. Tal vez bloquear
usuarios después de tres fallas no es importante en este momento, porque de todos
modos solo hay un puñado de usuarios en la primera versión. O tal vez se pueda
restablecer una contraseña enviando un correo electrónico a un empleado de atención
al cliente por el momento. De nuevo, al dividir la funcionalidad, podemos hacer

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 preguntas con mayor precisión sobre el valor del negocio y tomar decisiones en
consecuencia.

Estrategia 4: Desglose por opciones de entrada/plataforma

La mayoría de las aplicaciones web tienen que soportar varias opciones de entrada y/o
plataformas, como computadoras de escritorio, tabletas, teléfonos móviles o pantallas
táctiles. Puede ser beneficioso descomponer elementos grandes según sus opciones
de entrada.

Ejemplo: Tablero Scrum (Scrum board) digital para un equipo:

Como miembro del equipo,

quiero ver el tablero Scrum

para conocer como estamos en el equipo.

Podemos identificar las siguientes opciones de entrada:

 Como miembro del equipo, quiero ver el tablero Scrum en mi escritorio, así sé el
estado del Sprint;
 Como miembro del equipo, quiero ver el tablero Scrum en mi teléfono móvil, así sé el
estado del Sprint;
 Como miembro del equipo, quiero ver el tablero Scrum en una pantalla táctil, así sé el
estado del Sprint;
 Como miembro del equipo, quiero ver el tablero Scrum en una impresión, así sé el
estado del Sprint;

Al desglosar los ítems grandes de esta manera, el Product Owner puede priorizar más
fácilmente qué opciones de entrada o plataformas son más importantes. Es probable
que una versión de escritorio sea suficiente por ahora, mientras que una versión móvil
puede ser empujada a un Sprint futuro. O tal vez la impresión se puede implementar
con una simple captura de PDF por el momento, sin tener que crear una versión
adecuada para la impresión.

Estrategia 5: Desglose por tipo de dato o parámetros

Algunas historias de usuarios se pueden dividir en función de los tipos de datos que
devuelven o los parámetros que deben manejar.

Ejemplo: Función de búsqueda para una tienda en línea:

Como cliente

quiero buscar productos

para poder verlos y pedirlos.

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 Existen muchas formas de buscar un producto. Todos estos parámetros potenciales se
pueden considerar y dividir en historias de usuarios más pequeños:

 Como cliente quiero buscar un producto por su número de producto, así puedo
encontrar rápidamente un producto que ya conozco;
 Como cliente, quiero buscar productos en un rango de precios, para que los resultados
de búsqueda sean más relevantes;
 Como cliente quiero buscar productos por su color, para que los resultados de
búsqueda sean más relevantes;
 Como cliente, quiero buscar productos en un grupo de productos, para que los
resultados de búsqueda sean más relevantes;

Al desglosar la funcionalidad de búsqueda de esta manera, comprendemos más

claramente qué tipo de parámetros de búsqueda se utilizarán. Esto nos permite
estimar con mayor precisión la funcionalidad, pero también permite que el Product
Owner tome decisiones sobre la prioridad. Quizás la búsqueda no sea relevante
debido a la pequeña cantidad de productos. Podría ser relevante cuando crezca la
cantidad de productos. O tal vez parte de la funcionalidad de búsqueda se puede
implementar de manera simplificada por ahora. Otro ejemplo de esta estrategia es
cuando se rompe la funcionalidad que involucra información de gestión basada en los
tipos de datos que regresan. Parte de la información se puede presentar visualmente
en cuadros o gráficos (data types), pero también se puede mostrar en un formato
tabular (datatypes) por ahora. Tal vez el Product Owner está de acuerdo con exportar
los datos a Excel y crear manualmente todos los gráficos y tablas por el momento.

Estrategia 6: Desglosado por operaciones

Las historias de usuario a menudo implican una serie de operaciones

predeterminadas, como Crear, Leer, Actualizar o Suprimir (comúnmente abreviado
como CRUD). Las operaciones de CRUD son muy frecuentes cuando la funcionalidad
implica la gestión de entidades, como productos, usuarios u órdenes:

Como propietario de la tienda,

quiero administrar los productos en mi tienda web,

para actualizar el precio y la información de los productos si estos cambian.

Al identificar las operaciones individuales requeridas para esta funcionalidad, se puede

dividir en pequeñas funcionalidades:

 Como propietario de la tienda, quiero agregar nuevos productos para que los clientes
puedan comprarlos;
 Como propietario de la tienda, quiero actualizar la información de los productos
existentes, así puedo ajustar los cambios en los precios o la información del producto;
 Como propietario de tienda, quiero eliminar productos, así puedo eliminar productos
que ya no tengo en existencia;
 Como propietario de tienda, quiero ocultar productos, por lo que no pueden venderse
por el momento;

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 Cuando se presenta esta estrategia, muchos equipos se preguntan si los ítems más
pequeños realmente brindan valor de negocio. Después de todo, ¿de qué sirve crear
entidades solo cuando no puedes actualizarlas o eliminarlas después? Pero tal vez el
Product Owner tiene una cantidad limitada de productos, que la edición o eliminación
se puede hacer en la base de datos directamente. A veces, una operación se puede
implementar fácilmente en una forma simplificada. Eliminar un producto se puede
hacer de dos maneras; puede eliminar completamente el registro y todos los registros
asociados, o puede “eliminar logicamente” un producto. En ese caso, el producto aún
está en la base de datos, pero está marcado como “eliminado”. A veces, uno de estos
enfoques es más fácil de implementar y, por ahora, puede ser “lo suficientemente
bueno”.

Estrategia 7: Desglosado por “escenario de prueba”/”caso de prueba”

Esta estrategia es útil cuando es difícil desglosar historias de usuarios grandes

basadas en la funcionalidad sola. En ese caso, ayuda preguntar cómo se probará una
pieza de funcionalidad. ¿Qué escenarios deben verificarse para saber si la
funcionalidad funciona?

Ejemplo: Planificación de tareas:

Como gerente,

quiero asignar tareas a los empleados,

para que puedan trabajar en tareas.

Si consideramos esta funcionalidad en función de los posibles escenarios, podemos

desglosar el elemento en:

 Caso de prueba 1: si un empleado ya está asignado, no puede asignarse a otra tarea;

 Caso de prueba 2: si un empleado ha informado que está enfermo, debe estar
marcado visualmente;
 Caso de prueba 3: si un empleado se ha reportado enfermo, no se lo puede asignar a
una tarea;
 Caso de prueba 4: si un empleado aún no está asignado, se lo puede asignar a una
tarea;
 Caso de prueba 5: los empleados pueden ser asignados con un monitor de pantalla
táctil;

Esta estrategia realmente te ayuda a aplicar implícitamente las otras estrategias. Al

pensar en las pruebas, automáticamente se obtiene una serie de reglas de negocio
(Nro. 1, Nro. 2, Nro. 3 y Nro. 4), flujos infelices (Nro. 1, Nro. 2 y Nro. 3) e incluso
opciones de entrada (Nro. 5). Algunas veces, los escenarios de prueba pueden ser
muy complicados debido al trabajo involucrado para configurar las pruebas y trabajar a
través de ellas. Si un escenario de prueba no es muy común para comenzar o no
presenta un riesgo lo suficientemente alto, un Product Owner puede decidir omitir la
funcionalidad por el momento y enfocarse en escenarios de prueba que entreguen
más valor. En otros casos, los escenarios de prueba se pueden simplificar para cubrir
los problemas más urgentes. De cualquier forma, los escenarios de prueba relevantes

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 pueden traducirse fácilmente en elementos atrasados y agregarse al Sprint o al
Backlog.

Estrategia 8: Desglosando por roles

Las historias de los usuarios a menudo implican una cantidad de roles (o grupos) que
realizan partes de esa funcionalidad. Tome una historia de usuario para publicar
nuevos artículos en un sitio web de un periódico público:

Como organización de noticias,

quiero publicar nuevos artículos en nuestra página de inicio,

para que los clientes tengan una razón para regresar periódicamente.

Al considerar los diversos roles que están involucrados, podemos dividir la

funcionalidad en los siguientes bits:

 Como cliente, puedo leer un nuevo artículo, para poder informarme de eventos
importantes;
 Como periodista, puedo escribir un artículo para que nuestros clientes lo puedan leer;
 Como editor, puedo revisar el artículo antes de ponerlo en el sitio, de modo que
podamos evitar errores tipográficos;
 Como administrador puedo eliminar artículos del sitio, de modo que podamos retirar
artículos ofensivos;
 Como cliente, puedo revisar y confirmar mi pedido, para poder corregir los errores
antes de pagar;

Al desglosar la funcionalidad en roles que tienen que realizar partes de esa

funcionalidad, comprendemos mejor qué funcionalidad se necesita y podemos estimar
con mayor precisión en el trabajo involucrado. Escribir Historias de Usuario es una
gran manera de aplicar esta estrategia. También ayuda al Product Owner a priorizar.
Algunos roles pueden ser menos relevantes en este momento y pueden
implementarse más adelante. Tal vez no sea necesario en ese momento para un
editor. O el editor puede ser llamado por un periodista para verificar el artículo
manualmente.

Estrategia 9: Desglosando por “optimizar ahora” vs “optimizar más tarde”

Frecuentemente, las historias de los usuarios se pueden implementar en diversos

grados de perfección y optimización de la funcionalidad descrita.

Ejemplo:

Como visitante,

quiero buscar hoteles en un vecindario,

para así restringir mi búsqueda.

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 Una historia como esta se puede dividir en diversos grados de optimización:

 Como visitante, quiero buscar hoteles basados en un radio desde una dirección, de
modo que pueda restringir mi búsqueda;
 Como visitante, quiero ingresar el código postal para completar automáticamente la
dirección, así no tengo que ingresar la dirección completa manualmente;
 Como visitante, quiero usar mi ubicación (GPS) para buscar en el vecindario, así no
tengo que ingresar la dirección manualmente;
 Como visitante quiero obtener de inmediato los hoteles más buscados en el
vecindario, mientras que otros hoteles se cargan en segundo plano, por lo que
obtengo resultados más rápidamente;

Permítanme ser claro en una cosa: se supone que esta estrategia no debe usarse
como una excusa para escribir “código malo” ahora y “código mejor” en el futuro. Los
equipos Scrum siempre deben esforzarse por ofrecer un código que se pueda
mantener, (automáticamente) probado y bien escrito. Esta estrategia se refiere a la
optimización funcional. En cualquier caso, un Product Owner puede priorizar más
fácilmente estos ítems. Quizás sea suficiente por ahora permitir que los visitantes
busquen por dirección (y un radio), mientras que en el futuro se implementa una
funcionalidad más compleja (autocompletado, GPS).

Estrategia 10: Desglosando por compatibilidad con el navegador

En una variante de la estrategia Nro. 4, las historias de usuarios para aplicaciones web
a menudo necesitan trabajar en una amplia variedad de plataformas de
navegación. Los navegadores modernos tienden a ser más compatibles con los
estándares y más fáciles de desarrollar, mientras que los navegadores más antiguos a
menudo requieren hacks y personalizaciones para que todo funcione correctamente.

Ejemplo:

Como cliente

quiero ver los detalles del producto,

para saber si quiero comprarlo.

Al considerar las versiones de navegador, podemos dividir el trabajo en elementos

más pequeños:

 Como cliente, quiero ver los detalles del producto en un navegador moderno y
compatible con los estándares, así sé si quiero comprarlo;
 Como cliente, quiero ver los detalles del producto en IE7, así sé si quiero comprarlo;
 Como cliente, quiero ver los detalles del producto en un navegador de texto, por lo que
sé si deseo comprarlo;

Aunque sin duda sería preferible ofrecer esta funcionalidad con soporte completo para
todas las versiones de navegador, existen escenarios donde este desglose es factible.
Tal vez la gran mayoría de los visitantes utilizan navegadores modernos, que
requieren menos esfuerzo para soportar navegadores antiguos (que no sean un
warning). O tal vez la aplicación se ejecuta en una red interna donde todos los

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/
 usuarios usan Internet Explorer 7. De nuevo, esto permite que el Product Owner
priorice, y ayuda al equipo a dedicar primero tiempo y esfuerzo a la funcionalidad más
importante.

Otras estrategias

Existen otras estrategias que son útiles al desglosar historias de usuarios grandes:

 Desglosar los ítems basándose en los criterios de aceptación identificados.Esto puede

parecer muy obvio, pero a menudo es la manera más fácil y natural de desglosar una
historia. El trazado de los criterios de aceptación para las historias de un usuario
requiere estrategias similares a las descritas previamente;
 Desglosar los ítems según las partes que son difíciles de implementar y las partes que
son más fáciles.Puede ser difícil configurar una pieza de funcionalidad en una interfaz
de usuario muy diseñada, pero hacer que funcione con una interfaz de usuario simple
puede ser fácil y suficiente por ahora. Nuevamente, se trata de ser pragmático y
proporcionar valor comercial;
 Desglosar los ítems basándose en dependencias externas.En ocasiones, la
funcionalidad depende de factores externos, como la implementación de un
consumidor para un servicio web remoto (por ejemplo, para el pago electrónico o para
conectarse a Twitter). Esto puede ser difícil, pero puede no tener la más alta
prioridad. O las dependencias pueden ser burladas por el momento;
 Desglosar los ítems según los requisitos de usabilidad.Esto incluye la funcionalidad
para buscar a través de una lista de registros, hacer que un sitio web sea legible para
personas ciegas o personas con daltonismo o que implementen migas de pan;
 Desglosar los ítems según los requisitos de SEO, como la configuración de páginas de
destino específicas para palabras clave específicas, la creación de objetivos para
Google Analytics o la configuración de mapas de sitio XML;

¿Cuándo una Historia de Usuario es lo suficientemente pequeña?

No existe una regla clara sobre cuán pequeña debería ser la Historia de Usuario. Esto
depende en gran medida de la duración de los Sprints, la naturaleza de la aplicación y
el tamaño y la experiencia del equipo. A menudo se necesita varios Sprints para que
un equipo Scrum pueda descubrir el punto óptimo.

Mi experiencia me dice que los equipos deben esforzarse por agregar al menos entre
5 historias en un Sprint de una semana (una por día). No tienen que ser del mismo
tamaño, pero no deberían ser demasiado grandes por sí mismos. Cuando los equipos
usan la estimación de Story Point, a menudo acuerdan el tamaño máximo para que
una historia llegue al Sprint. De modo que una historia solo se tomará en el Sprint si es
menor a (digamos) 8 puntos. Esto también le da un objetivo claro al proceso de
refinamiento del próximo trabajo.

http://marcoviaweb.com/estrategias-para-descomponer-historias-de-usuario/