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

Dividir una historia de usuario significa dividir una historia demasiado extensa en historias más pequeñas, cada una de las cuales sigue aportando algo que el usuario puede 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 ni de 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 valores de 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.
• Se puede describir 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 es precisamente 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 diferentes tamaños trabaja conjuntamente con planning poker, una amplia dispersión es la señal más útil que se obtiene. Unas cartas que van del 3 al 13 no reflejan un desacuerdo numérico. Se trata de dos historias 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.
• Una persona 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, no ofrecer una estimación más precisa. Lo que sí funciona es dividirlo: en un pico si lo desconocido es la causa, en secciones verticales si lo desconocido es 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 —una porción delgada que realmente se pueda entregar por sí sola— y no horizontal. «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 permite entregar 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 al completo.

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 consultar. Hay otros patrones que se repiten con suficiente frecuencia como para que merezca la pena mencionarlos.

Pasos del flujo de trabajo

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

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, aunque no tenga confirmación por correo electrónico, sigue pudiendo 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 inferior mientras tanto y, de hecho, vuelva a ocuparse de ello posteriormente.

Calidad diferida

Lance la versión sin los detalles finales —sin información sobre herramientas, sin animaciones, sin modificaciones administrativas— y, a continuación, lance los detalles finales como una historia independiente. Esto funciona si realmente lanza los detalles finales. Los equipos que dejan de lado 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 y 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, sino un aplazamiento de la entrega, ya que ninguna de las dos partes se entrega 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 su parte complementaria se ha implementado, no ha dividido la historia. Simplemente la ha programado.

Cuando no sea posible dividir una noticia: publique una noticia de última hora

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 definido 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», sino una historia sin estimar que incluye pasos adicionales. Hay dos indicios de que está utilizando la herramienta equivocada: que no se responda a ninguna pregunta concreta o que el resultado esperado sea «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, 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 lanzaría al mercado.

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

Divídalo antes de que comience el sprint, de forma deliberada. Una historia que no quepa se traslada de forma inadecuada —lo que queda es precisamente lo más complicado— 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, sino que 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 una duración determinada, que se lleva a cabo cuando el equipo no puede estimar el tamaño de una historia sin obtener más información. El resultado es conocimiento —un documento, un prototipo, una medición— y 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 — el centro de referencia para todo lo relacionado con este tema.
• División de la historia de SPIDR — Las cinco líneas de corte fiables, en profundidad.
• División horizontal frente a vertical — el principio en el que se basa toda buena división.
• Definición de «listo» — el hito que debe superar una historia dividida antes de volver a incorporarse al sprint.
• Refinamiento de la cartera de proyectos — el proceso en el que se lleva a cabo realmente la división.