15 preguntas clave para realizar una buena división de historias de usuario.

En este artículo presentaremos 15 preguntas clave que te ayudarán a evaluar si una determinada historia de usuario puede ser susceptible de ser dividida para poder cumplir con los principios INVEST.

Índice de contenidos


1. Introducción

La división de historias de usuario es un arte que uno mismo va mejorando a través de la experiencia, y que si eres una persona muy perfeccionista, seguramente siempre estés intentando verificar si la historia que acabas de generar es “perfecta”.

Para aportar más a la causa, en este artículo os presento las 15 preguntas clave que podemos plantearnos para verificar si nuestra historia ha alcanzado un cierto grado de perfección, y que sin duda cumple con los principios INVEST.


2. ¿Por qué debería leer este artículo?

Cuando se generan las historias de usuario (H.U.) en las que se desglosará nuestro proyecto, no siempre es fácil hacer que cumplan los principios INVEST (sobretodo, si es de las primeras veces que creamos historias).

Existe mucha documentación al respecto sobre estos principios, por lo que vamos a recordar muy rápidamente qué significado tiene el acrónimo INVEST antes de entrar en faena.

  • I: Independant
  • N: Negotiable
  • V: Valuable
  • E: Estimable
  • S: Small
  • T: Testable

Por lo tanto, cada una de nuestras H.U. deberían ser independientes unas de otras, deberían aporten valor al usuario final, deberían poder ser estimadas y lo suficientemente pequeñas como para poder abordarlas en un sprint, y sin duda, deberían estar formuladas para que puedan ser testeadas convenientemente.


3. Las 15 preguntas clave para realizar una buena división de Historias de Usuario

A continuación evaluaremos una teórica H.U. recién creada, que por ejemplo, acabemos de generar en nuestro backlog.

3.1 Evaluando la H.U. creada

Disponemos de nuestra H.U. recién creada, y queremos evaluar si debemos dividirla o no. Para ello, podemos plantearnos a las siguientes preguntas:

  • ¿La historia recién creada cumple con los criterios INVEST?
  • ¿El tamaño de la historia es de 1/10 a un 1/6 de la velocidad del equipo?

Si no cumple con los criterios INVEST, entonces podemos combinarla con otra historia o bien, reformularla para obtener una buena historia de la que partir.

Si el tamaño de la historia no está encuadrada en esta fracción de velocidad del equipo, entonces podemos asegurar que nuestra historia es demasiado grande, y que por lo tanto necesitamos dividirlas.

Y os podéis preguntar, ¿y qué pasa si todavía no conozco la velocidad de mi equipo?, pues puedes basarte en tu propia experiencia con equipos anteriores para tener una aproximación.

3.2 Aplicando patrones de división de historias

Imaginemos por tanto, que en base a las preguntas anteriores, concretamos que necesitamos dividir nuestra historia de usuario.

Para dividirla podemos atender a diversos criterios, evaluando si nos aplican o no a través de las siguientes preguntas:


3.2.1 División en base al workflow de la historia

En caso de que la historia de usuario contenga algún tipo de workflow, podemos plantearnos las siguientes preguntas:

  • ¿Se podría dividir la historia para que se haga el principio y el final del workflow primero, y posteriormente enriquecer el grueso del workflow a través de otras historias?
  • ¿Se podría dividir la historia para que se realice la forma más básica posible del workflow, y posteriormente ir enriqueciendo el mismo con otras historias?

3.2.2 División en base a las operaciones que se realizan

En caso de que la historia de usuario incluya múltiples operaciones, es decir, esté relacionada con “administrar” o “configurar” algo, podemos plantearnos las siguientes preguntas:

  • ¿Se podrían separar las operaciones en distintas historias de usuario?

3.2.3. División en base a las variaciones en las reglas de negocio

En caso de que la historia de usuario contenga reglas de negocio, existe la posibilidad de que la historia establezca conceptos que puedan sugerir variaciones en dichas reglas, por ejemplo, términos como “fechas flexibles“. En ese caso:

  • ¿Se podría dividir la historia para abordar primero un subconjunto de las reglas, y enriquecerlas con historias adicionales posteriormente?

3.2.4. División en base a las variaciones en los datos

En caso de que la historia de usuario establezca que se debe realizar la misma acción en diferentes juegos de datos, deberíamos plantearnos la siguiente pregunta:

  • ¿Se podría dividir la historia para procesar un único tipo de dato primero, y aumentar los tipos de datos soportados con historias posteriores?

3.2.5. División en base a las variaciones en la interfaz

Para el caso de que la historia disponga de una interfaz compleja, podemos plantearnos las siguientes preguntas:

  • ¿Se podría identificar una versión reducida del interfaz que se pudiera hacer primero?

Por otra parte, para el caso en el que nuestra historia de usuario sugiera que debe recibir el mismo tipo de datos a través de múltiples interfaces, podemos plantearnos que:

  • ¿Se podría dividir la historia para manejar los datos a través de un único interfaz al principio, e ir enriqueciéndolo con historias posteriores?

3.2.6. División en base a simplicidad / complejidad

En caso de que dentro de nuestra historia hayamos identificado un core simple que proporcione la mayor parte del valor de la historia, podemos plantearnos:

  • ¿Se podría dividir la historia para construir primero ese core, y posteriormente ir enriqueciéndolo con nuevas historias?

3.2.7. División en base a retrasar los requerimientos no funcionales

En caso de que en la historia se identifique excesiva complejidad para satisfacer requerimientos no funcionales, como por ejemplo, el rendimiento, nos podemos plantear:

  • ¿Se podría dividir la historia para construir los requisitos funcionales primero, y posteriormente cumplir los requisitos no funcionales del producto con historias posteriores?

3.3 Evaluando la división de la historia

Una vez que hemos aplicado uno o varios patrones de división de historias de usuario a través de estas preguntas, toca evaluar si la historia ha quedado suficientemente dividida pudiendo utilizar la siguientes preguntas:

  • ¿Las nuevas historias de usuario resultantes, son relativamente iguales en tamaño?
  • ¿Cada una de las nuevas historias son aproximadamente de 1/10 a 1/6 de nuestra velocidad de equipo?
  • ¿Cada una de las nuevas historias satisface los principios INVEST?
  • ¿Han aparecido historias que pueden bajar su prioridad, o incluso, ser borradas?
  • ¿Ha aparecido una historia muy obvia con la que empezar, por que es la que nos va aportar el máximo valor de forma temprana, o conocimiento, o va a mitigar el riesgo, etc..?

En caso de que a cada una de estas preguntas hayamos contestado con un , hemos concluido con éxito la división de nuestra historia de usuario, aunque podríamos seguir evaluando si aplicando distintos patrones de división funciona mejor.

En caso de que a alguna de estas preguntas, la respuesta haya sido un NO, debemos evaluar el uso de otro patrón de división de historia a nuestra historia original, con el objetivo de ir refinando la misma y obtener una buena historia de usuario.


4. Conclusiones

Como comentábamos al inicio de este artículo, la división de la historia de usuario perfecta viene con el tiempo y la experiencia (e incluso podemos plantear si existe la H.U. perfecta).

Con este conjunto de preguntas, podremos evaluar si nuestra historia de usuario puede ser susceptible de ser dividida, y por lo tanto, podamos conseguir una H.U. que cumpla con los principios INVEST.


5. Referencias