¿Qué hacer ante una historia de usuario que no es divisible y no cabe en un sprint?

Estimando una historia de usuario grande

Es usual que equipos que se inicien en Scrum no sepan o no crean posible dividir las historias de usuario en elementos tan pequeños como para que quepan en un sprint de dos semanas. Están acostumbrados a construir funcionalidades a lo largo de semanas o meses y son escépticos ya que no ven sprints de dos semanas con 5 o 6 historias.

Existen historias de usuario que no se pueden dividir, las denominadas historias complejas que son fundamentalmente grandes, pero son excepciones muy muy raras.

Veamos un ejemplo en un diseñador de informes, un elemento que ayudó a crear Manuel, un alumno, en uno de sus proyectos. Incluía una parte visual donde el usuario componía el informe como un puzzle, y otra en donde se tomaba esa composición y se convertía en una consulta SQL para enviar a la base de datos. Según él esa historia seguramente representaría un sprint de un mes para un equipo pequeño, quizás más.

Lo que nos dice Scrum es que las historias de usuario deben de ser lo suficientemente pequeñas para caber en un sprint, por tanto hay que dividir la historia de usuario. Veamos qué podemos hacer:

Podemos dividir en historias según
el esquema de base de datos
Cortesía de Pixabay

Posiblemente el diseñador de informes se base en más de una tabla, o en unas cuantas decenas de campos. Una forma de dividir el informe podría ser: hacer en el primer sprint todo el informe completo pero que solo trabaje con la tabla principal y con los 10 campos que más valor de negocio tengan... y de sprint en sprint vamos añadiendo tablas y campos, siempre según el valor de negocio que aporten. De esa forma si en el 4 sprints por ejemplo, resultase que el usuario se ha dado cuenta que no sabía de una tabla muy importante, o se había olvidado de ella (somos humanos), o se ha creado una tabla nueva, no hay ningún problema en adaptarse e incluir lo que sea. Del mismo modo, si descubrimos tablas y campos sin valor, y esas inevitablemente se irán dejando para futuros sprints, llegará un momento en que quizá debamos de plantearnos si tiene sentido incluirlas.

Bien, resulta que no somos capaces de dividir la historia y necesitamos dos sprints, ¡la excepción confirma la regla! Hacer en el primer sprint la consulta SQL y mostrarla en la revisión de sprint. Obtendremos feedback de los usuarios y el Propietario del Producto, sobre si esos son los campos que quieren, de si la consulta devuelve la información esperada y de si es eso lo que necesitan. La clave en Scrum está en la constante inspección y adaptación, los puntos de feedback y de aprendizaje.

Si nos llevaramos historias muy grandes a los sprints gastaríamos tiempo dentro del sprint para entenderla, lo que implica incertidumbre y riesgo, las divisiones en el refinamiento y en la planificación de sprint dan un entendimiento mas profundo de la historia.

Una de las disfunciones clásicas es cuando el equipo está insistiendo en que las historias grandes de la pila de producto no se pueden dividir en más pequeñas. Como Scrum Master debemos de tratar esa disfunción, uno de los métodos eficaces es mostrarles cómo dividir una historia de un ejemplo real que sea familiar para el equipo. Una vez hecho esto, es muy difícil seguir argumentando que no es posible dividir esa historia.

Otro aspecto importante es la motivación general del equipo para dividir historias, podemos trabajar con el hecho de que los equipos se motivan al finalizar historias pequeñas y sienten el logro cada vez que lo hacen.