¿Tamaño y nivel de detalle adecuados para una historia de usuario?

Introdución.

Uno de los aspectos que genera más confusión a la hora de entender las historias de usuarios es su tamaño. Esto se debe a que no hay un único tamaño adecuado para una historia de usuario, sino que este depende de la distancia en el tiempo al momento de desarrollar la historia.

El tamaño de una historia de usuario es proporcional a la cantidad de funcionalidad que abarca (alcance), y por tanto también es proporcional a la cantidad de riesgo e incertidumbre que contiene.

Otro aspecto confuso es el nivel de detalle de la historia de usuario. Este está relacionado con lo precisa que necesita ser la historia de usuario, ya que los detalles acotan y aclaran los límites de la historia. Aquí ocurre un fenómeno similar al que comentamos para el tamaño, es decir, no existe un único nivel de detalle adecuado para una historia de usuario, sino que este cambiará según nos acercamos al momento de desarrollar una historia.

En este post vamos a intentar arrojar un poco de luz sobre estos dos aspectos de las historias de usuario,

¿Cómo deberían variar el tamaño y el nivel de detalle adecuados de una historia de usuario?

Según nos acercamos al momento de desarrollar la historia, nos interesa que ocurran los siguientes fenómenos:

1. Que su tamaño disminuya.
2. Que su nivel de detalle aumente.

Relaciones entre la evolución del tamaño y el nivel de detalle.

Existe una curiosa relación entre el tamaño y el nivel de detalle.

Si miramos con atención como acotamos el alcance de una historia de usuario^[1], podemos observar que detallar la historia siempre es un paso previo para reducir el tamaño de la historia.

Vamos a poner un ejemplo, dada esta historia de usuario:

Quiero ordenar productos.

Si detallamos lo que significa ordenar, nos quedaría:

Quiero ordenar productos

* Por fecha de compra.

* Por coste del producto.

que, obviamente, tiene el mismo tamaño pero más nivel de detalle.

Si decidimos partir esta historia en dos, nos podrían salir las siguientes historias:

Quiero ordenar productos por su fecha de compra.

y

Quiero ordenar productos por su coste.

Ahora cada una tiene menor tamaño pero conservando el nivel de detalle de la inicial. Por tanto, vemos que existe una relación entre detallar una historia de usuario y reducir su tamaño, ya sea partiéndola o no^[2].

¿Por qué dependiendo del momento el tamaño y el nivel de detalle adecuados varían?

Hay al menos dos momentos del tiempo dónde debería cambiar el tamaño de las historias para que sea eficiente trabajar con ellas.

El primer momento, T_r, ocurre poco antes de presentar una historia al equipo en, la que suele denominarse, sesión de refinamiento. El segundo momento es poco antes de T_d. T_d, como indica la gráfica, es el momento en que desarrollamos la historia.

Idealmente no debería pasar demasiado tiempo entre T_r y T_d.

Analicemos cada uno de ellos.

Nivel de detalle adecuado dependiendo del momento.

Desde su creación, (T₀), hasta antes del momento (T_r).

Detallamos poco principalmente porque queremos evitar tanto malgastar tiempo (waste) como descartar posibles opciones interesantes.

Hay varias formas en las que podemos incurrir en waste. En este caso concreto, se podrían presentar dos formas de waste:

1. Trabajo innecesario. Cuanto más alejados estamos de T_r mayor es la incertidumbre sobre qué historias de usuario acabarán desarrollándose o no, por tanto, si invertimos mucho tiempo en detallarla en este momento, la probabilidad de desperdiciar tiempo y energía en un trabajo innecesario es alta^[3]. La inversión en detallar se materializaría como trabajo innecesario si al final no se acaba desarrollando la historia^[4].

2. Recuperación de contexto como forma de retrabajo. Si ha pasado mucho tiempo desde la última vez que se trabajó en la historia, necesitamos volver a hacer un esfuerzo para recordar qué aspectos se discutieron tiempo atrás^[5].

En cuanto a mantener las opciones abiertas, nos referimos a no tomar decisiones que puedan descartar opciones antes de tener suficiente información, ya que si las tomamos prematuramente existe una mayor probabilidad de que estas sean erróneas ^[6]. Por tanto, para mantener nuestras opciones abiertas lo mejor es no decidir hasta el último momento responsable.

En T_r.

En este caso el detalle que vamos a añadir tiene como finalidad hacer la historia más pequeña. Hablaremos sobre esto en la sección de relacionada con el tamaño adecuado de una historia de usuario.

Poco antes de T_d.

Finalmente, en este momento necesitamos detallar mucho más porque queremos eliminar cualquier posible ambigüedad en las historias de usuarios para desarrollarlas sin malentendidos y suposiciones erróneas.

Los criterios de aceptación^[7] y los ejemplos sirven para detallar mejor una historia de usuario y aumentar su claridad.

La razón por la que queremos ganar claridad es para asegurar uno de los aspectos más importantes de las historias de usuario, la confirmación^[8]. Es decir, queremos ser capaces de determinar cuándo una historia de usuario está acabada y funcionando como se esperaba.

El uso de ejemplos en las historias de usuario juega un papel muy importante porque clarifican los criterios de aceptación que normalmente están en un nivel de abstracción mayor.

Por ejemplo, dada una historia relacionada con el registro de usuarios en una site internacional de venta de bebidas con bajo contenido alcohólico podríamos tener el siguiente criterio de aceptación:

Debe ser mayor de edad.

Si agregamos unos cuantos ejemplos podríamos aclarar la complejidad que ese criterio de aceptación podría estar ocultado para algunos de los participantes en la sesión de refinamiento.

Dado que resido en Japón y tengo 18, cuando intento registrarme, me indica que soy menor de edad y no me deja finalizar el registro.

Dado que resido en Alemania, tengo 18 y he rellenado correctamente los otros datos del formulario, cuando finalizó el registro, veo un mensaje de agradecimiento por el registro.

Al escribir ejemplos podrían emerger varios escenarios. Por tanto, los ejemplos no sólo clarifican, sino también pueden ayudar a preguntarnos sobre otros escenarios posibles^[9].

Siguiendo con el caso expuesto, podríamos preguntarnos: ¿Qué escenario no me permite registrarme si resido en Alemania? ¿Cuántos países tenemos que tener en cuenta?.

Es importante además que todas las partes involucradas en las historias de usuario (Producto, Devs, QAs, etc) estén de acuerdo sobre los criterios de aceptación. Esta claridad compartida ayuda a que todos los participantes comprendan mejor la situación y reduce la posibilidad de que se produzcan diferentes interpretaciones sobre lo que cada uno espera de la historia de usuario.

Tamaño adecuado dependiendo del momento^[10].

Desde su creación, (T₀), hasta antes del momento (T_r).

Las historias pueden tener un tamaño muy grande, y esto es lo adecuado, ya que nos interesa que su tamaño sea grande porque, como explicamos más arriba, aún no tenemos información suficiente para reducir su tamaño.

Además existe mucha incertidumbre sobre qué historias acabarán desarrollándose o no, y por tanto, la probabilidad de desperdiciar tiempo y energía intentando reducir su tamaño es muy alta.

Por ejemplo podríamos plantear una historia de usuario como la siguiente:

Marketing necesita informes para evaluar el impacto de las acciones realizadas.

Aunque esta historia abarca mucha funcionalidad, al menos deja abierta los tipos de informes que podrían aportar más valor. Así, si más tarde cambian las necesidades o se descubren otros informes que aportan más valor, ese cambio de decisión no afecta a la historia.

De hecho, si, de antemano, reducimos todas las historias lo más posible acabaremos en lo que se conoce como el “user story card hell”^[11].

En T_r.

En este momento se da una tensión entre dos necesidades.

Por un lado queremos reducir el tamaño de la historia de usuario para que las reuniones con el equipo sean lo más efectivas posible, pero, no queremos reducirlo demasiado para no cerrar opciones antes de examinarla en la reunión de refinamiento.

El riesgo de reducir demasiado el tamaño de la historia de usuario antes de la reunión de refinamiento es que podríamos crear un efecto de framing en el equipo, que reduciría su capacidad para proponer alternativas más creativas o económicamente más interesantes.

Acertar con el tamaño adecuado en el momento, T_r, es a veces complicado porque hay que equilibrar los dos objetivos en tensión, conseguir una reunión eficiente y no cerrar demasiado las opciones. Nuestro consejo es no preocuparse en exceso para no caer en parálisis por análisis. Con el tiempo iremos aprendiendo a equilibrar ambos objetivos.

Por ejemplo, la anterior historia podría convertirse en la siguiente:

Como usuario del Departamento de Marketing, quiero generar informes de los cambios de planes de nuestros suscriptores para evaluar el impacto de las campañas.

Lo que reduciría el tamaño de la historia de usuario pero dejando aún algunas opciones abiertas.

Poco antes de T_d.

En este momento, el contexto cambia de manera radical. Ahora lo que buscamos es que las historias sean lo más pequeñas posibles.

Los motivos por los que tratamos de reducir las historias de usuario lo más posible son:

• Entregar valor lo antes posible, de forma que el usuario pueda obtener beneficio de una parte lo antes posible. En este sentido las historias de usuario representarían posibles incrementos de valor.

• Reducir riesgo. Con incrementos pequeños de funcionalidad se reduce el riesgo de desviarnos de lo que espera el usuario, al tiempo, que se reduce el riesgo de incurrir en retrabajo y el de introducir errores.

• Ciclos de feedback cortos. Los incrementos pequeños de funcionalidad nos permiten experimentar, aprender, ajustar nuestras prioridades y tomar mejores decisiones.

Siguiendo con el ejemplo anterior, la historia puede convertirse en la siguiente:

Como usuario del Departamento de Marketing, quiero generar un informe de los aumentos de planes contratados en los últimos 30 días para evaluar el impacto de las campañas mensuales”.

* Mostrar fecha del informe.

* Mostrar la cantidad total de planes que han aumentado.

En este ejemplo se reduce el tamaño de la historia al detallar que sólo nos preocupa cuándo hay un aumento de planes contratados (y no un descenso), la fecha del informe y la cantidad total de planes contratados en ese periodo.

En futuras versiones, podríamos plantearnos refinar este aspecto pero ahora Marketing ya está obteniendo al menos un informe que le proporcionará una buena parte del valor que inicialmente necesitaba.

Conclusión.

Hemos visto cómo tenemos que ajustar el tamaño y nivel de detalle de las historias de usuario a medida que nos vamos acercando al momento en que se desarrolla una historia.

Desde su creación, (T₀), hasta antes del momento (T_r), cuando hay mayor incertidumbre, las historias son más grandes y menos detalladas, lo que permite mantener opciones abiertas y evitar esfuerzos innecesarios.

Poco antes de una reunión de refinamiento (T_r), las historias que vamos a presentar en ella deben ajustarse en tamaño y detalle lo suficiente como para fomentar discusiones efectivas, pero evitando cerrar nuestras opciones prematuramente.

Finalmente, al llegar al momento del desarrollo (T_d), las historias deben ser pequeñas y bastante detalladas para eliminar ambigüedades, reducir riesgos y permitir entregas incrementales de valor. También vimos una relación importante, que detallar una historia de usuario es lo que permite reducir su tamaño, ya que el detalle aclara el alcance y esto facilita dividirla, si fuera necesario, en historias más pequeñas sin perder claridad. En futuros posts seguiremos profundizando en este tema dando heurísticas que pueden ayudarnos a escribir historias de usuario adecuadas para dos de los momentos importantes que hemos comentado en este post: antes de presentar la historia en una una reunión de refinamiento (T_r), y justo antes de empezar a desarrollarla, (T_d).

Agradecimientos.

Nos gustaría darle las gracias a Ivan Samkov por la foto del post.

Notas.

[1] Este paso no tiene porque ser realizado de manera explícita pero es un paso implícito que se produce cuando intentamos hacer la historia más pequeña. Podríamos acabar con una sóla historia y a la vez implícitamente estar descartando otras opciones que podrían estar presentes en la historia inicial.

[2] Sería posible que sólo nos preocupara ordenar por fecha de compra y entonces la historias quedaría directamente como “Quiero ordenar productos por fecha de compra”.

[3] También es posible que haya un cambio de prioridad pero la probabilidad de que esto ocurra es mayor cuanto más alejado estamos de T_d.

[4] Un efecto, que hemos observado, que puede estar escondiendo el posible desperdicio generado, es caer en el sesgo del coste hundido para no tirar a la basura la inversión que ya hemos hecho, aunque haya otra solución mejor.

[5] Es curioso observar que para reducir el problema del olvido, se suele anotar más detalles. Eso provoca que aumente el tiempo invertido en un momento en el que la incertidumbre es mayor y por tanto aumentan las posibilidades de haber hecho trabajo innecesario.

[6] El principio del último momento responsable, También es un problema tomar decisiones de manera tardía porque pueden generar pérdida de oportunidades y retrabajo para terceros.

[7] Algunos autores usan el concepto de condiciones de satisfacción o rules para hablar de los criterios de aceptación por diferentes motivos. Mike Cohn prefiere utilizar condiciones de satisfacción y en Example Mapping se utiliza el concepto de Rules.

[8] Card, Conversation, Confirmation son 3 aspectos esenciales enunciados por Ron Jeffries en su artículo de 2001

[10] Liz Keogh documenta una serie de patrones conversacionales al trabajar con ejemplos que pueden ser muy útiles para explorar los ejemplos en Conversational patterns in BDD.

[9] Si bien existen criterios para juzgar si el tamaño de una historia es adecuado, como por ejemplo INVEST, no todos los criterios son aplicables, o si lo son, no con el mismo peso en cada uno de los momentos, t₀, t_r y t_d. Además, si fuera necesario, hay diversas técnicas para dividir historias de usuario, o, en algunos casos, incluso fusionarlas.

[11] “Story card hell is when you have 300 story cards and you have to keep track of them all” from Beyond Story Cards: Agile Requirements Collaboration.