Scrum: qué no debería tener una historia de usuario

Hernán Ricardo Ortiz
21 de marzo de 2019
4 min. de lectura
h_como_no_escribir_HU

Con frecuencia encontramos en artículos, en libros y hasta en los cursos de certificación de roles de un equipo de Scrum, cómo se debería escribir una historia de usuario (HU), cuáles son sus características o qué deberíamos cumplir.

No obstante, cuando nos enfrentamos a la vida real es común escuchar de parte de los integrantes del equipo Scrum frases como: “Esa historia de usuario no está bien escrita”, “le falta esto, lo otro” o “podría haberla escrito mejor”:

Es ahí cuando notamos que en la práctica no es tan fácil, que con los ejemplos previos no alcanza. Por ello, hoy quiero compartirles algunas malas prácticas bastantes comunes (prefiero malas prácticas a errores) que utilizamos a la hora de la construcción de historias de usuario.

Ya nos han dicho mucho cómo hacerlo “bien”, pero no qué evitar. Por ello, les daré una lista de lo que no debes hacer. 

1. Crear historias de usuario de relleno

Cuando nos encontramos en el proceso de descubrir necesidades o en la etapa de desarrollo, escuchamos frecuentemente en algunos eventos, la siguiente frase “... entonces, creemos una historia de usuario con eso” o “agreguemos eso a X historia de usuario” y nos vamos llenando de basurita o cosas que no generan valor para el negocio.

¿Cómo podemos mejorarlo?

En caso de ser necesario, agregar o modificar una HU, debemos medir o evaluar el impacto positivo que genere al adicionarla al product backlog. Cuando hablamos de valor, nos referimos a la solución potencial de las necesidades del negocio.

El beneficio puede ser económico, emocional, experiencia del usuario, normativo, operativo o legal; depende de la perspectiva de negocio que me podrá generar al implementarla. Para saber más sobre este marco de trabajo ágil, lee: Fundamentos de Scrum

2. Volver una Historia de usuario un documento de requisitos

Es una situación común en equipos solucionadores que deseen el más mínimo detalle sobre la necesidad (reflejado en la HU) para implementarla “mejor” o para cuando surja un cambio, es decir “eso no estaba escrito en la HU, entonces no se puede hacer”, estas prácticas van en contra de algunas premisas del agilismo como disminuir la documentación o la flexibilidad a los cambios.  Ver Principios Manifiesto ágil

historias de usuario

¿Cómo podemos mejorarlo?

Las HU's deberían tener únicamente el texto necesario para entender la necesidad por parte del equipo y de las personas interesadas; nos podemos apoyar en complementos o anexos a las historias de usuario. Por ejemplo, relacionar el diagrama que muestra el flujo de proceso, una hoja de cálculo que muestra el listado de campos de una pantalla y sus características, un prototipo de pantalla o cualquier otro artefacto que el Product Owner o  que el equipo solucionador considere necesario.

3. Cero colaborativo, cero conversacional

Aquella frase: “Si no está escrito, no vale”, en nuestro contexto sería algo así: “Si no está escrito, no se desarrolla”. Falso, lo más valioso de las HU's  es el componente conversacional, por algo es una de las 3 C's (Card, conversational, confirmation). Está muy relacionado con la práctica anterior.

¿Cómo podemos mejorarlo?

Las HU’S son una invitación a conversar.

¿Quiénes son los invitados? normalmente el Product Owner (dueño del producto) y el equipo solucionador; pero se puede integrar a los interesados e involucrados en el momento que sea necesario.

Eventos como el refinamiento y el planning propician dichas conversaciones poderosas con el fin de facilitar el entendimiento de la necesidad y que el equipo se conecte con  el valor negocio que se busca con la implementación

Esta dinámica fomenta el trabajo colaborativo y permite mantener una comunicación fluida entre los miembros del equipo Scrum. Así, la historia va cambiando durante la ejecución del sprint y se va perfeccionando en conjunto.

4. Conversemos más

¿Y entonces quién las escribe? Si apelamos al purismo del framework, se suele indicar que las historias de usuario son responsabilidad exclusiva del Product Owner.  En la práctica, es de todas las personas involucradas en la generación de valor con el desarrollo del producto.

Es normal ver en algunos equipos, que el Product Owner no está 100 por ciento en el proyecto, entonces, se designan miembros del equipo que ayudan en la construcción. Lo que no puede suceder es que la historia llegue al equipo solucionador sin la aprobación y priorización del  Product Owner. Lee: ¿Cómo funciona Scrum? 

Historias de usuario en Scrum

Si bien, el dueño del producto tiene la responsabilidad de priorizar o aprobarlas, las historias se van modificándose por la influencia y aportes de quienes forman parte del equipo solucionador, todos somos responsables de cuestionar y cuestionarse a sí mismos sobre la historia, cada quién desde el rol que desempeñe en el equipo Scrum, puede aportar desde su experiencia o conocimiento para construir mejores  historias de usuario.

5. Historias de usuarios muy grandes

No aplicar patrones de división correctos (HU Front- HU Back). En algunos equipos es normal ver en el backlog HU´s que tienen el mismo nombre, pero diferente apellido, por ejemplo:

  • HU01 Login Front
  • HU02 Login Back
  • HU03 Login Integración ……. y así;

Primero tendríamos que evaluar y preguntarnos qué valor generaría entregar una HU solita, después lo que probablemente suceda es que tengamos solo la HU 001 Login (Incluye Back, Front, Integración) y en el planning se divida en actividades de desarrollo por cada una de las capacidades, este sería el mejor escenario; pero qué hacemos si el equipo nos dice lo siguiente:

“Señor(a) Product Owner con la capacidad del equipo no alcanzamos a entregar la historia de usuario en un sprint”; tendríamos que pensar cómo dividir nuestra HU,  y que al dividirla cada parte genere valor por sí misma, en este momento utilizamos una herramienta poderosa, aplicamos patrones de división, estos serían algunos ejemplos aplicados:  

  • Tecnología de acceso (primero app y despues portal)
  • Fuentes de información (Primero un sistema y en otras iteraciones integramos los demás)
  • Tipos de usuarios ( Primero para el rol con el que genere mayor valor y después integramos al resto)

El Product Owner deberá tener claro qué partes debemos implementar primero, siempre pensando en que nos genere el mayor valor.

Espero que la información haya sido de mucho valor para construir o tener mejores Historias de usuario durante la implementación del marco de trabajo Scrum.

Conoce la guía funcional de Scrum

Te puede interesar

Otros artículos de Transformación digital

Suscríbete