10 estrategias útiles para descomponer Historias de Usuario grandes (y una chuleta). Basado en el...

1. Estrategias

2. ¿Por qué y cuando descomponer las historias de usuario grandes?

2.1. ¿Por qué?

2.1.1. Las historias de usuario muy grandes son más difíciles de entender y de estimar, lo que aumenta la probabilidad de fallar en un sprint

2.2. Cuando

2.2.1. En la reunión de planificación de un nuevo sprint

2.2.2. En las reuniones de refinamiento del backlog

3. ¿Por qué es mejor descomponer las historias verticalmente en vez de hacerlo horizontalmente?

3.1. Descomposición horizontal

3.1.1. ¿Qué es?

3.1.1.1. La descomposición de la historia por la clase de trabajo que hay que hacer o por los niveles arquitectónicos involucrados, por ejemplo; interfaz de usuario, BBDD, Front-end, componentes, back-end, etc.

3.1.1.2. Es como cortar una tarta de manera horizontal, por sabores, de manera tal que los pedazos resultantes van a tener un sólo sabor

3.1.2. Desventajas

3.1.2.1. Las historias resultantes no acaban como software funcionado de manera global, sólo se pueden mostrar las partes por separado

3.1.2.2. Incrementa los cuellos de botella en vez de reducirlos

3.1.2.3. Las historias descompuestas horizontalmente no pueden ser priorizadas

3.2. Descomposición vertical

3.2.1. ¿Qué es?

3.2.1.1. La descomposición de la historia a nivel de niveles funcionales

3.2.1.2. Es como cortar una tarta verticalmente para que cada pedazo tenga todas las capas de sabores que tiene

3.2.2. Ejemplo

3.2.2.1. Como cliente quiero poder pagar mi pedido para obtener mis productos

3.2.2.1.1. Como cliente quiero poder pagar mi pedido por transferencia bancaria para obtener mis productos

3.2.2.1.2. Como cliente quiero poder pagar mi pedido tarjeta de crédito para obtener mis productos

3.2.3. ¿Cuándo una historia se puede considerar lo suficientemente pequeña?

3.2.3.1. Generalmente depende de

3.2.3.1.1. La longitud de los sprints

3.2.3.1.2. La naturaleza de la aplicación

3.2.3.1.3. El tamaño y la experiencia del equipo

3.2.3.2. Generalmente a un equipo scrum le toma varios sprints encontrar el tamaño ideal

3.2.3.3. La experiencia personal del autor dice que un equipo debería poder hacer al menos 5 historias en un sprint de una semana (una por día)

3.2.4. Sobre las posibles preocupaciones del equipo Scrum con respecto a descomponer las historias de usuario

3.2.4.1. Valor reducido de negocio de historias de usuario pequeñas

3.2.4.1.1. El propósito principal de descomponer las historias de usuario es reducir el riesgo, incrementar el flujo y la cantidad de funcionalidad trabajando que puede ser revisada al final de cada sprint

3.2.4.2. Descomponer las funcionalidades resulta en más trabajo

3.2.4.2.1. En Scrum implementamos un proceso de revisión y prueba continua de nuestro trabajo y se ajusta según el feedback obtenido, por lo que la funcionalidad puede cambiar de lo que es ahora a lo que será al final, por lo que puede ser un desperdicio trabajar en una gran historia que puede ir cambiando mucho con el tiempo

3.2.4.3. No saber como descomponer las funcionalidades

3.2.4.3.1. La mejor forma de enfrentar esto es persistir y hacer coaching al equipo para ayudarlos a descomponer sus historias de usuario