División de historias de usuario que no caben en un sprint

Dividir una historia de usuario consiste en dividir una historia demasiado amplia en historias más pequeñas, cada una de las cuales siga aportando algo que el usuario pueda utilizar. Una historia que no se puede estimar suele ser una que aún no se puede entregar, y dividirla es la medida que permite volver a incluirla en el tablero.

La mayoría de las conversaciones del tipo «no podemos estimar esto» son, en realidad, conversaciones sobre la división de tareas encubiertas. El equipo no tiene un problema de cifras y esfuerzo; tiene un problema de demasiadas incógnitas. La división reduce las incógnitas hasta que la historia adquiere la forma de un trabajo que ya se ha realizado anteriormente, y las estimaciones convergen.

Cuándo dejar de hacer estimaciones y empezar a dividir

Una historia que no cabe en un sprint no es un problema de tamaño, sino de forma. Esté atento a las señales:

• El equipo vota por los valores 13 y 20, y luego sigue votando una y otra vez para llegar a un consenso en lugar de dividirse.
• «Depende» responde a más de un par de las preguntas de precisión.
• La historia abarca el ámbito de más de un equipo.
• La opción «Hecho» requiere varias implementaciones.
• Puede describirlo en dos frases, pero no en dos criterios de aceptación.

Si, a pesar de todo, sigue adelante, el equipo se pasa todo el sprint intentándolo y aplaza lo que queda (lo cual es un error, ya que lo que se aplaza suele ser lo más difícil) o bien termina una parte que se puede entregar y da el trabajo por concluido, mientras que el resto queda a medio hacer. Ambas opciones son peores que dividir el trabajo a propósito antes de que comience el sprint.

Por qué una amplia diferencia de votos implica una división y no una nueva votación

Cuando un equipo de un determinado tamaño trabaja con el «planning poker», una amplia dispersión de las puntuaciones es la señal más útil que se obtiene. Un rango de puntuaciones que va del 3 al 13 no es una discrepancia numérica. Se trata de dos perspectivas diferentes que pretenden ser una sola. Quien vota un 3 ve un alcance; quien vota un 13 ve otro alcance. Volver a votar no servirá para conciliarlos; la tarea consiste en mantener una conversación sobre cuál de los dos alcances es el real. Esto es lo que suele estar ocurriendo en el fondo:

• Una persona se encarga de evaluar el escenario ideal; otra, de evaluar los casos extremos.
• Una persona da por hecho que el diseño ya existe; otra da por hecho que es ella quien lo está diseñando.
• Una persona se encarga de evaluar el alcance de la consulta; otra, de evaluar el alcance de la implantación.
• Una persona sabe que existe esa dependencia; la otra, no.
• Hay una persona que está evaluando a alguien que se encuentra en la sala; el trabajo corresponde a otro equipo.

Aportar más detalles rara vez resuelve este problema: lo único que consigue es alargar el ticket, en lugar de ofrecer una estimación más precisa. Lo que sí funciona es dividirlo: en un pico si la incógnita radica en la causa, y en segmentos verticales si la incógnita radica en el alcance. El hecho de que haya dos tarjetas separadas no significa que el equipo esté en desacuerdo. Significa que el equipo está votando sobre historias diferentes. Devuélvalo.

Corte en sentido vertical, no horizontal.

La división debe ser vertical, no horizontal: una porción delgada que realmente se pueda entregar por sí sola. «Primero el backend, el frontend en el siguiente sprint» divide la historia del mismo modo que un cuchillo corta la masa: se obtienen dos mitades que no aportan nada. Una porción vertical abarca todas las capas y entrega una columna funcional, un botón que funciona de principio a fin, aunque solo gestione un caso de entrada. Consulte «División horizontal frente a vertical» para conocer el principio en su totalidad.

Esquemas de división que funcionan

SPIDR (pico, ruta, interfaz, datos, reglas) abarca la mayoría de las situaciones de división, y es lo primero que hay que tener en cuenta. Existen otros patrones que se repiten con la suficiente frecuencia como para que merezca la pena mencionarlos.

Pasos del flujo de trabajo

Una historia que abarca el recorrido de un usuario (registrarse, configurar preferencias, confirmar el correo electrónico, consultar el panel de control) suele dividirse claramente en función de los límites entre los distintos pasos. Cuando funciona, es la técnica más clara de todas las disponibles: cada historia ofrece un elemento reconocible y visible para el usuario, cada una puede mostrarse en una demostración y cada una puede definirse por sí sola.

La prueba consiste en una única pregunta, que se plantea en cada paso: ¿Se beneficiaría el usuario de esto si lo lanzáramos sin nada más? «Configurar preferencias» supera la prueba: un usuario con preferencias, pero sin confirmación por correo electrónico, sigue encontrándose en un estado en el que puede utilizar el servicio. «Enviar formulario» no supera la prueba: un usuario cuyo envío no llega a ninguna parte se encuentra en una situación peor que antes. Si la respuesta es «no», el paso es una subtarea, no una historia, y el flujo de trabajo no se divide en ese punto.

La versión más ágil de la misma prueba: ¿podría cada paso llegar a producción en el plazo de tres sprints sin que cambiara nada más, y ofrecer una experiencia coherente en cada etapa? Si al omitir un paso el usuario se encuentra con una página que no funciona, la división es falsa. Esa es la trampa en la que caen los equipos de ingeniería: los pasos se corresponden con la forma en que se descompone el código (servicio de autenticación, API de preferencias, componente del panel de control), por lo que parecen granular. Son granular. También son secciones horizontales con terminología de flujo de trabajo superpuesta, y ninguna de ellas entrega nada al usuario. La clave: cada «paso» es responsabilidad de un único especialista. Los pasos reales del flujo de trabajo atraviesan toda la pila, porque así lo hacen los pasos reales orientados al usuario.

Variaciones en las reglas de negocio

Una historia que incluya varias reglas o roles (usuario habitual, administrador, cliente de API) se divide por reglas. Implemente primero la regla más común; a continuación, las variantes. Cada variante constituye una historia independiente con sus propios usuarios.

Ruta favorable y, a continuación, ruta desfavorable

Está estrechamente relacionado con el enfoque Path de SPIDR. Implemente primero la ruta normal; la gestión de errores, los reintentos y los casos extremos vendrán después. El usuario puede obtener un resultado satisfactorio incluso antes de que se hayan gestionado por completo los modos de fallo, siempre y cuando acepte un comportamiento de fallo menos óptimo mientras tanto y se ocupe de ello posteriormente.

Calidad diferida

Lance la versión sin los toques finales (sin información sobre herramientas, sin animaciones, sin modificaciones administrativas) y, a continuación, lance los toques finales como una historia independiente. Esto funciona si realmente lanza los toques finales. Los equipos que descuidan la calidad y nunca vuelven sobre ello acaban con funcionalidades a medias de forma permanente.

Operaciones

Una historia que combina una funcionalidad para el usuario con aspectos operativos (registro, supervisión, alertas) se divide según esa línea. Lance primero la parte dirigida al usuario; la parte operativa es una fase posterior que suele ser más rápida, ya que la funcionalidad ya está en producción y las deficiencias son visibles.

¿Qué no es una separación real?

«Frontend en este sprint, backend en el siguiente» no es una división; es aplazar la entrega, ya que ninguna de las dos partes lanza nada por sí sola. «Desarrollarlo primero y luego escribir las pruebas» sigue el mismo patrón: el código sin probar es un riesgo, no una parte. Si una tarea solo tiene valor una vez que se ha implementado su parte complementaria, no ha dividido la historia. Simplemente la ha programado.

Cuando no sea posible dividir una noticia: publique una noticia breve

A veces, lo desconocido es el propio alcance: nadie lo ha hecho antes, la API del proveedor no responde a la pregunta clave sobre la capacidad de carga, o el trabajo depende de una medición de la que aún no se dispone (p99 actual, volumen de llamadas actual, estructura de datos actual). Es entonces cuando se lleva a cabo un «spike»: una investigación con un plazo determinado cuyo resultado es conocimiento (un documento, un prototipo, una recomendación, una medición), y no código de producto listo para su lanzamiento. Al finalizar, se está en condiciones de estimar con honestidad la realidad del proyecto.

Los «spikes» se utilizan erróneamente con la idea de «empecemos y veamos qué pasa». Eso no es un «spike»; es una historia sin estimar con pasos adicionales. Hay dos indicios de que está utilizando la herramienta equivocada: no se responde a ninguna pregunta concreta, o el resultado esperado es «la función está desarrollada». Lo primero significa que el equipo no tiene realmente dudas; lo segundo significa que se trata de una historia.

Si una sola fase sigue sin bastar, significa que el proyecto aún no está listo; se trata de un proyecto. Defínalo como tal, comunique el calendario y deje de fingir que un sprint será suficiente.

Preguntas frecuentes

¿Cómo se divide una historia de usuario?

Divídalo verticalmente, en función de los resultados para el usuario, de modo que cada segmento abarque todas las capas y ofrezca algo que el usuario pueda utilizar, aunque solo resuelva un caso concreto. SPIDR propone cinco líneas de división fiables: pico, ruta, interfaz, datos y reglas. Elija aquella que le permita obtener un segmento que realmente pueda lanzar al mercado.

¿Qué hace usted cuando una historia de usuario es demasiado extensa para un sprint?

Divídala antes de que comience el sprint, a propósito. Una historia que no quepa se traslada de forma inadecuada (lo que queda es precisamente lo más difícil) o se entrega como un subconjunto a medio desarrollar. Ambas opciones son peores que una división vertical deliberada en partes que se entreguen por separado.

¿Cuándo conviene dividir una historia en lugar de realizar una estimación?

Cuando el equipo no puede incluirla en un sprint, cuando las puntuaciones varían mucho (un 3 junto a un 13), cuando la respuesta «depende» se repite en más de un par de preguntas de refinamiento, o cuando la historia abarca a más de un equipo. Una gran diferencia en las puntuaciones no es un desacuerdo numérico; se trata de dos historias que pretenden ser una sola.

¿Qué es un «spike» en el método ágil?

Un «spike» es una investigación con un plazo determinado, que se lleva a cabo cuando el equipo no puede estimar el alcance de una historia sin obtener más información. El resultado es conocimiento (un documento, un prototipo, una medición), no código de producto listo para su lanzamiento. Hay dos elementos que lo convierten en un «spike» y no en un trabajo de duración indefinida: un plazo y un resultado concreto.

¿Cuáles son las formas más habituales de dividir una historia de usuario?

Pasos del flujo de trabajo, variaciones de las reglas de negocio, la ruta normal y la ruta anómala, calidad diferida y cuestiones operativas, además de los cinco criterios SPIDR. La prueba para todos ellos es la misma: ¿se beneficiaría el usuario si se lanzara esta parte y nada más?

Lecturas relacionadas

• «Estimación ágil: la guía completa» es el punto de referencia para todo lo relacionado con este tema.
• El artículo sobre la división de historias de SPIDR analiza en profundidad las cinco líneas de corte fiables.
• La división horizontal frente a la vertical es el principio en el que se basa toda buena división.
• La definición de «listo» es el hito que debe superar una historia dividida antes de volver a incorporarse al sprint.
• El refinamiento de la cartera de proyectos es la sesión en la que se lleva a cabo la división.