5 errores al desglosar historias de usuario y como dejar de cometerlos (traducción al castellano)

Sabemos que tener un Product Backlog actualizado y priorizado es algo fundamental para los equipos agiles, sin embargo en ocasiones nos encontramos con historias de usuario que son demasiado grandes y complejas que no permiten esto. Cuando deseamos desglosar estas historias mucha veces nos topamos con una serie de inconvenientes que no permiten obtener historias de usuario adecuadas, es por ello que en este post traemos la versión traducida al castellano del artículo: “Five Story-Splitting Mistakes and How to Stop Making Them por Mike Cohn”

Splitting User Story

En el momento en que comienza una iteración, las historias de usuario seleccionadas deben ser lo suficientemente pequeñas como para que se puedan completar en la iteración. Esto hace que desglosar historias sea una habilidad importante en todos los equipos ágiles.

Sin embargo, sospecho que todos hemos tenido problemas con el desglose de historias en algún momento. Muchos de esos problemas son el resultado de un conjunto de errores comunes. En este post abordaré cinco de los errores de desglose de historias más comunes y ofreceré consejos sobre cómo dejar de hacerlos.

# 1. Tratar el desglose de historias como un trabajo exclusivo del Product Owner

En la parte superior de mi lista de problemas comunes está la referida al desglose de historias como algo que el Product Owner puede hacer solo. Cuando solo el Product Owner desglosa las historias, es bastante probable que las nuevas sub-historias no se desglosen de una manera muy útil.

Por ejemplo, dado que la mayoría de los Product Owners tienen poca o ninguna experiencia técnica, ellos pueden desglosar una historia de usuario en cinco subcategorías pero dejar el 99% del trabajo en solo una de las historias.

Desglosar una historia de esa manera no es útil. De forma similar, sin una formación técnica, el Product Owner podría crear nuevas subcategorías con dependencias entre ellas y que impidan completarlas en una única iteración.

Si bien el desglose de historias no debe considerarse como responsabilidad exclusiva del Product Owner, este debería participar siempre. Tampoco la responsabilidad debe confiarse únicamente al equipo de desarrollo, para que las historias se desglosen de manera óptima, el Product Owner debe estar presente.

Esto significa que el desglose debe verse como una actividad de todo el equipo. Sin embargo esto no involucra que todo el equipo deba participar en todos los desgloses, más bien significa que esta actividad no debe delegarse a una o dos personas para que realicen todo el trabajo. En lugar de ello, dos compañeros del equipo pueden unirse al Product Owner para desglosar una o dos historias, más tarde, otro miembro del equipo y yo podríamos ayudar al Product Owner a desglosar la siguiente historia.

Se recomienda que el desglose de historias pueda ser comentado en un Daily Scrum. El Product Owner puede aparecer y anunciar la necesidad de desglosar historias en los siguientes días como preparación para el próximo sprint, para lo cual algunos desarrolladores indicarán que están disponibles para ayudar y se elige una hora en ese momento.

# 2. Desglose de historias desde una perspectiva técnica

Mientras entreno a los equipos para que durante el desglose soliciten ayuda al equipo de desarrollo, concretarlo puede conducirnos a nuestro segundo problema: desglosar historias desde una perspectiva técnica en lugar una funcional. Probablemente has visto historias que sufren de este problema, a menudo, estas son las historias que se escriben así: “Como programador, quiero …” y describen la funcionalidad desde el punto de vista del equipo en lugar de un usuario final o una parte interesada.

Realizar el desglose desde una perspectiva técnica puede generarnos las siguientes historias:

  • Como usuario, quiero un back-end que haga tal y tal
  • Como usuario, quiero una interfaz que haga lo mismo tal y tal

Una buena historia es aquella que atraviesa un bloque entero de tecnología. O al menos la mayor cantidad de tecnología que se necesita para entregar un feature. Las historias desglosadas a lo largo de límites técnicos nos dan historias que no aportan ningún valor a los usuarios por sí mismas. Una interfaz (por ejemplo, una interfaz web) no sirve a los usuarios hasta que se interactúe con un backend (una capa intermedia y/o base de datos).

Para evitar caer en la trampa de desglosar una historia desde una perspectiva técnica, vea si puede realizar el desglose en función de los caminos (camino feliz y caminos no felices) o escenarios que involucra la historia.

Para desglosar una historia en caminos, piense en los diferentes escenarios que afrontara el código que el equipo escribirá. A menudo hay un camino feliz, que define lo que ocurre si todo va bien. Generalmente, también hay un camino para cada error que puede ocurrir.

También puede pensar en los caminos que un usuario puede tomar al interpretar la historia que debe desglosarse. Por ejemplo, considere una historia de pago de los artículos en un carrito de compras, ya que ese es un ejemplo que se aplicaría a cualquier sitio de comercio electrónico. Al momento de pagar, el comprador puede seleccionar un método de envío, tal vez eligiendo entre entrega durante la noche, entrega en dos días o una entrega más lenta.

Ya que la elección de un método de envío influenciara en el esfuerzo para desarrollar la historia, considere dejar esa funcionalidad fuera de una implementación inicial. Quizás una primera versión asume que todos reciben una entrega lenta sin opción de envío más rápido. Desarrollar solo esa ruta a través de la implementación simplifica la interfaz de usuario (no es necesario permitir que un usuario seleccione las opciones de envío), reduce el número de casos para probar, y así sucesivamente. Dividir por escenario sería una opción muy viable en una situación como esta.

# 3. Especificar la solución como parte de la historia

Un tercer error que veo a menudo en el desglose es especificar la solución como parte de la historia. Las mejores historias de usuarios se centrarán en lo que se necesita hacer y no en cómo se hará.

Por ejemplo, ahora mismo tengo una foto que quiero colgar en la pared de mi oficina. Si tuviera que pedirle a alguien que lo haga por mí, podría decirles cómo quiero que se haga. Podría decir que quiero que cuelgue con un perno de palanca de cabeza de hongo de ⅜ “. Con esto he especificado mucho cómo hacerlo. A menos que los detalles exactos me importen, será mejor que me quede con lo que quiero: “Me gustaría que esta imagen se cuelgue de forma segura en ese lugar en esa pared”.

Incluir la solución dentro de una historia tiende a suceder cuando las historias se dividen demasiado. Una vez que una historia llega a un cierto tamaño pequeño, no hay mucho más para decir sobre la historia y los detalles de implementación comienzan a aparecer cuando no deberían.

Por ejemplo, suponga que estamos construyendo un cajero automático (ATM) para dispensar. Este es un ejemplo clásico que a menudo se da en los libros de requisitos de software. Se usa para señalar que al especificar lo que se necesita en nuestro nuevo cajero automático no debemos suponer que el cajero automático usará un código PIN y una tarjeta para autenticar a un usuario solo porque así es como siempre lo hemos hecho. Después de todo, quizás esta vez usaremos un escáner de retina.

Comenzar con una historia que es simplemente “El usuario se autentica a sí mismo” es una buena idea y el cómo queda fuera de esa historia. Pero a medida que la historia se desglosa cada vez más, eventualmente alguien necesita decir si estamos usando un escáner de retina o un teclado tradicional y un lector de tarjetas. Por lo tanto, si encuentra que su equipo incluye muchos detalles sobre cómo se implementará una historia, considere si está dividiendo historias de manera que sean más pequeñas de lo que deberían ser.

# 4. Usando un Spike en cada historia

Un Spike es un esfuerzo realizado por un equipo para desarrollar nuevos conocimientos en lugar de nuevas funcionalidades. Los picos se usan a menudo para reducir el riesgo o la incertidumbre en una historia. Si un equipo no está seguro o no está familiarizado con una nueva tecnología, puede ejecutar un Spike para que puedan obtener más información sobre la tecnología.

Desglosar un Spike fuera de una historia puede ser un buen enfoque. Reduce la incertidumbre en la historia inicial, lo que probablemente hará que la historia tarde menos en desarrollarse. Pero ejecutar un Spike también puede ayudar a un equipo y al Product Owner a descubrir nuevas formas de desglosar mejor la historia si todavía es demasiado grande después del Spike.

Por lo tanto, extraer un Spike de una historia es una buena idea en algunos casos. Pero el error que algunos equipos cometen es depender demasiado de los Spikes. Algunos equipos llegarán a dividir un Spike en cada historia.

Mala idea.

Los Spikes son más útiles cuando una historia incluye una cantidad excesiva de incertidumbre, y cuando el equipo y el propietario del producto acuerdan que la incertidumbre debe reducirse antes de implementar la historia. Un Spike no debe usarse cuando una historia tiene una cantidad diaria común de incertidumbre.

La incertidumbre existe hasta cierto punto en cada historia. ¿Les gustará a los usuarios si se hace de esa manera? ¿Este diseño funcionará adecuadamente? ¿Funcionará esta nueva herramienta tan bien como el vendedor dijo que lo haría? Estos, o algunos como ellos, son preguntas que existen en cada historia. El objetivo de un Spike no debe ser eliminar toda incertidumbre. En la mayoría de los casos, eso sería imposible de todos modos hasta que se escriba la línea final.

En cambio, los Spikes deberían reservarse para cuando la historia de un usuario contenga tanta incertidumbre que comenzar la historia en serio sería un error sin el conocimiento que se obtendría del pico.

Los equipos que separan los Spikes de las historias con demasiada frecuencia lo hacen a menudo por miedo a equivocarse en las estimaciones. El equipo siente que serán castigados, o al menos criticado, si una historia tarda más en desarrollarse de lo que estiman. Estos equipos a menudo se encuentran en culturas que confunden estimar con cometer. Para superar este problema, desactive las estimaciones o trabaje para crear seguridad a su alrededor, de modo que los equipos no teman que cada estimación se use en su contra.

# 5. Pensar en que todas las reglas de negocios deben aplicarse desde el principio

A veces, una historia de usuario se hace difícil de implementar debido a las reglas que la historia debe cumplir. A menudo se llaman reglas de negocio porque la operación de la empresa generalmente es la fuente de ellas. Sin embargo, en otras ocasiones pueden considerarse reglas impuestas por el sistema. Déjame ilustrar esto con un ejemplo.

Supongamos que forma parte de un equipo que trabaja en un banco que realiza préstamos hipotecarios. Su equipo está desarrollando una nueva aplicación móvil que los clientes del banco utilizarán para solicitar préstamos hipotecarios. Quizás una regla establecida en su banco es que nadie puede tener más de $ 10 millones en préstamos hipotecarios pendientes. Esta regla se aplica si el prestatario desea un préstamo grande o si quiere un préstamo de $ 6 millones en un segundo hogar, además de un préstamo existente de $ 5 millones.

La nueva aplicación móvil de su equipo idealmente hará cumplir este máximo al no permitir que una persona presente una solicitud de préstamo que exceda los $ 10 millones en préstamos totales (ya sea el primer, segundo o décimo préstamo del prestatario).

Una regla como esta aumentará el esfuerzo para completar la historia del usuario porque la nueva aplicación móvil deberá buscar el saldo del préstamo existente, agregarlo al monto del préstamo solicitado y asegurarse de que la suma no supere los $ 10 millones.

Si esta regla hace que la historia dure tanto que no será factible implementar la historia en una sola iteración, la regla debería relajarse (o eliminarse) en la iteración inicial y luego volver a agregarse en una iteración posterior. Y, no, el equipo no debe lanzar un producto que viole las reglas comerciales (temporalmente).

El error que veré en los equipos es pensar que todas las reglas comerciales deben implementarse desde el principio. Esto a menudo lleva a un equipo y propietario del producto a utilizar una forma menos deseable de desglosar la historia.

En la próxima reunión en la que estará desglosando historias, busque maneras de implementar parcialmente una historia al no apoyar una regla inicialmente. Siempre que no tenga la intención de liberar el trabajo finalizado de esa iteración, encontrará que las reglas relajantes pueden ser una excelente manera de dividir una historia.

Qué hacer a continuación

El desglose de historias es uno de los desafíos más comunes que escucho de los equipos. En esta publicación, he cubierto cinco de los errores más comunes que veo que hacen los equipos y ofrecí sugerencias para superarlos.

Una de las mejores cosas que puede hacer para evitar errores de división de historias es volverse más experto en la división de historias. Afortunadamente, no son muy extensas las técnicas que necesita saber que le permitirán dividir cualquier historia.

En esta publicación mencioné tres de las técnicas, las cuales desglosaban historias por:

  • Path (camino feliz y caminos infelices)
  • Rules (reglas de negocio)
  • Spikes

Leave a Reply

Your email address will not be published. Required fields are marked *