Cuando trabajamos con metodologías ágiles, nuestra unidad de trabajo es la Historia de Usuario. Inicialmente nuestro Product Backlog está compuesto de épicas y features que no son implementables por si mismas, ya que probablemente requerirán que las descompongamos en unidades más pequeñas, que permitan ser asumibles por el equipo. No existe una regla única, básicamente es usar el sentido común y tener en mente algunos de los patrones de descomposición de historias de usuarios que vamos a ver en este artículo. Sobre todo es interesante realizar esta descomposición una vez hemos hecho un User Story Mapping.

Es bastante conocido, que una historia de usuario debe de cumplir con el modelo INVEST. Este acrónimo describe los siguientes principios:

• Independent: La historia de usuario debe permanecer independiente y no depender de otras, ya que las dependencias comprometen la planificación.
• Negotiable:  El contenido de las historias de usuario es adaptable mientras no se hayan incluido en el sprint. Los detalles de una historia de usuario se obtienen de la conversación, por lo que es importante aclarar y negociar la expectativa.
• Valuable:  Un principio importante y destacado en el manifiesto ágil es que la historia de usuario debe aportar valor al cliente, siendo este un punto clave. Una historia de usuario que no aporta valor no debería implementarse
• Estimable: Para poder decidir qué historias de usuario entran la iteración, es importante que la historia tenga e tamaño adecuado para poder estimar el tiempo que nos va a llevar implementarla. Es por ello importante que el alcance esté bien acotado.
• Small: La historia de usuario deben de poder cabernos en un sprint, por lo que es importante que la historia sea asumible en un tiempo no mayor de una semana.
• Testeable: La historia de usuario debe de definir las características y criterios de aceptación para poder escribir tests que cumplan con estos criterios.

Una vez descrito el principio INVEST, vamos a ver distintos patrones y ejemplos para detectar cuando una historia de usuario debe de partirse en historias más pequeñas:

Pasos de un workflow

Muchas veces una historia de usuario se compone de una serie de steps que definen un workflow. Es importante identificar estos steps y dividir la historia de usuario en elementos más pequeños que representen cada uno de estos steps y aporten valor por sí mismos.

Un ejemplo clásico es un un proceso de venta de un e-commerce que consiste en una serie de pasos a la hora de completar un pedido.

Imaginemos la siguiente historia de usuario:

• Como usuario quiero realizar un pedido para que llegue a mi domicilio

Esta historia de usuario sería muy ambiciosa, por lo que podríamos dividirla en historias de usuario por cada paso del funnel de venta:

• Como usuario quiero rellenar los datos de contacto para para que me identifiquen como el comprador
• Como usuario quiero rellenar los datos postales para para saber donde enviar mi pedido
• Como usuario quiero elegir el método de envío para que me llegue el pedido a mi domicilio
• Como usuario quiero elegir el método de pago para que poder pagar el pedid
• Como usuario quiero confirmar el pedido para que se termine de tramitar

Variaciones de reglas de negocio

Si la historia de usuario describe una serie de reglas de negocio seguramente podamos dividirlo en historias que cumplan cada una de esas reglas con un nivel de especificidad mayor.

Imaginemos la siguiente historia de usuario:

• Como usuario quiero filtrar productos para encontrar el producto adecuado

Esta historia sería muy ambiciosa, ya que deben definirse una reglas de negocio que especifiquen que filtros aportan valor y serían interesantes proporcionar al cliente para poder filtrar correctamente.  Una posible división sería:

• Como usuario quiero filtrar productos por categoría para poder ver productos de una gama
• Como usuario quiero filtrar productos por marca para poder ver productos de una marca específica
• Como usuario quiero filtrar productos por precio para poder ver los productos que se adecuan a mi presupuesto

Esfuerzo diferente

Muchas veces podemos dividir una historia de usuario, en la que un esfuerzo dedicado impactará a todas ellas, asumiendo la complejidad en una de ellas. Un ejemplo típico es la inclusión de una pasarela de pago, donde primero se debe de preparar el software para poder gestionar los pagos, pero posteriormente añadir nuevas pasarelas de pago requieren menos esfuerzo.

Imaginemos la siguiente historia de usuario

• Como usuario quiero poder user Paypal, Redsys, Stripe o American Express para pagar el pedido

Evidentemente, esta historia de usuario podríamos dividirla por cada una de las implementaciones necesarias para cada pasarela:

• Como usuario quiero poder usar Paypal para pagar el pedido
• Como usuario quiero poder usar Redsys para pagar el pedido
• Como usuario quiero poder usar Stripe para pagar el pedido
• Como usuario quiero poder usar American Express para pagar el pedido

Simple / Complejo

Cuando la complejidad de una historia de usuario se descontrola es probable que se puede dividir el problema en problemas mas simple. Esto implica considerar cada casuística como una historia de usuario diferente. Suelen aparecer estas casuísticas cuando nos preguntamos aspectos como ¿Qué pasa si…? ¿Hemos tenido en cuenta …? Lo ideal es una historia de usuario que resuelva el caso más simple y añadir historias de usuario para sus variaciones.

Imaginemos la siguiente historia de usuario:

• Como usuario quiero poder reservar vuelos entre un origen y destino, pudiendo indicar número de escalas y buscar fechas cercanas…

Como vemos, esta historia de usuario intenta abarcar distintas casuísticas a través del nexo ‘y’. Por ello lo ideal es definir la historia de usuario mas sencilla e incluir todas sus variantes:

• Como usuario quiero poder reservar vuelos entre un origen y un destino…
• Como usuario quiero poder indicar un número de escalas….
• Como usuario quiero poder buscar vuelos en fechas cercanas…

Conclusión de los patrones de descomposición de historias de usuarios

Como hemos visto en estas estrategias, lo más importante es usar el sentido común para poder escribir historias de usuario adecuadas y abordables por el equipo de desarrollo. Cuanto mayor sea el nivel de especificidad mucho mejor, ya que ayudará al equipo a no desviarse de la necesidad. Además de los patrones descritos, existen otras estrategias de descomposición como puede ser desglose por operaciones (dividir en operaciones CRUD) o desglose por roles (Identificar qué acciones hace cada tipo de rol).

Aquí os adjunto un artículo que detalla otras estrategias: https://www.agile42.com/en/blog/2015/04/08/techniques-breaking-down-technically-complex-user-stories/

¿Y tú? ¿Qué estrategia usas para descomponer las historias de usuario para que tengan un tamaño apropiado?