Historias de usuarios y alternativas
por Avi Schneier y Tom Bullock | 26 de agosto de 2020 | Blog
Si el Sprint es el corazón de Scrum, el Product Backlog es su columna vertebral.
Para ser eficaz, un Backlog debe estar compuesto por elementos individuales redactados de tal forma que el equipo entienda no sólo qué trabajo debe completarse, sino por qué.
Por esta razón, muchos equipos Scrum utilizan plantillas para escribir los elementos del backlog. Para un ojo inexperto, pueden parecer Mad Libs para profesionales.
Adopte el formato conocido como Historia de Usuario (describimos la fórmula a continuación). Esta fórmula es tan popular que puedes referirte a elementos individuales de tu Product o Sprint backlog como historias. "Quiero que todo el mundo recuerde algo antes de empezar a hablar de formatos", dice Avi Schneier, Consultor Principal de Scrum Inc., y añade que estas fórmulas "no forman parte oficialmente de Scrum. No aparecen en la Guía Scrum".
Sin embargo, son extremadamente útiles. Como afirma Avi, las Historias de Usuario y sus alternativas son una "práctica auxiliar que ha ayudado a muchos Equipos Scrum a lo largo de los años."
Sin embargo, el formato de historia de usuario no siempre es la mejor plantilla de Elemento de Backlog de Producto (PBI) que se puede utilizar.
Historias de usuarios
Las historias de usuario tienen sus raíces en el software. Concretamente, dice Avi, en los viejos tiempos de la programación. "Me refiero a los años setenta, ochenta", explica, cuando "los programas estaban pensados para personas con tantos conocimientos tecnológicos como quienes los escribieron.." Esto era estupendo para los que escribían el código. Pero daba lugar a programas problemáticos que confundían a los clientes.
Además, Avi afirma que este enfoque fallaba en el principio básico de cualquier negocio: ofrecer valor a los usuarios o clientes. "Los programadores necesitaban una forma de hablar de lo que estaban haciendo desde la perspectiva de para quién lo estaban haciendo". De ahí nació el formato de historia de usuario.
Aunque existen variantes, la fórmula clásica de la historia de usuario es la siguiente:
Como <WHO> Quiero o necesito <WHAT> para que <WHY>.
Cada negrita rellenada para terminar la plantilla.
Un ejemplo de "quién" es el usuario final. El "qué" define la capacidad solicitada y el "por qué" es el resultado deseado al utilizar el "qué".
Esta sencilla fórmula, centrada en el usuario final, revolucionó la programación y, al igual que el Scrum, se extendió mucho más allá del software y la informática.
Puntos fuertes de las historias de usuarios
Las historias de usuario se construyen en torno a la empatía con los usuarios finales. Al comenzar con el usuario final, el "quién" en mente, y construir el "qué" y el "por qué" en torno a esa persona, las Historias de Usuario mantienen al cliente y cómo van a utilizar el producto o servicio en primer plano.
Ese es el punto fuerte del formato Historia de Usuario.
Fomenta la comprensión "desde su perspectiva", explica Avi, "del dolor por el que están pasando literalmente al utilizar tu producto o servicio". Ya se trate de una silla de oficina que no se puede ajustar correctamente o de una característica de diseño de un programa informático que no funciona, Avi subraya que todos hemos sentido el dolor de un producto o servicio que se diseñó sin tener en cuenta al usuario final. Cuando se trata de deleitar a los clientes, "ese tipo de empatía es lo que buscamos. Es realmente poderosa".
Otro punto fuerte de las Historias de Usuario está en el nivel épico "porque ahí es donde el valor de su cliente es visible". Pero por definición, hay muchos PBI individuales que componen una epopeya.
Puntos débiles de las historias de usuarios
Las Historias de Usuario son, con diferencia, la plantilla más popular para los Elementos del Backlog de Producto. Pero, ¿son siempre la mejor opción?
La respuesta honesta es no.
Como señala Avi, incluso algunos de los primeros promotores del formato de historias de usuario han llegado a esta conclusión. "Si vas a Internet y pasas algún tiempo buscando en Google a las personas que crearon las Historias de Usuario, muchas de estas personas son ahora tremendos detractores de las Historias de Usuario. Creen que ya no sirven para nada".
Una de las principales razones es que el diseño de productos y servicios centrado en el usuario final es ahora la norma. O casi.
Otra, explica Avi, es el simple hecho de que hay un montón de PBI que no pueden ser fácilmente enfocados o escritos con un personaje de usuario final en su centro. "Sobre el terreno, he observado muchas veces que los equipos tardaban más en escribir el formato de historia de usuario que en resolver realmente el problema". Sobre todo cuando el trabajo a realizar no se centra en un ser humano.
En este caso, Avi pone dos ejemplos. Uno de software y otro de hardware.
El ejemplo del software se centra en tratar con una interfaz de programación de aplicaciones o API, "Donde una parte del programa está obteniendo datos y la API está recogiendo datos de una parte del sistema y luego enviándolos a otra parte del sistema". Como bien señala Avi, un formato de historia de usuario aquí suena extraño, ya que equivaldría a "como sistema, necesito que los datos del lugar A se envíen al lugar B para resolver la situación C".
A veces, las Historias de Usuarios pueden perder su eficacia incluso cuando un humano está directamente involucrado. Tome el acto de un conductor tratando de detener su coche. Sí, un humano está aplicando presión sobre el pedal del freno con un resultado deseado en mente, pero eso es realmente más una epopeya que un solo PBI ya que hay muchas partes de un sistema que necesitan interactuar con el fin de lograr ese resultado.
Si estás trabajando en un cilindro maestro, pregunta Avi, ¿escribes la historia pensando en el freno de disco? Si cada historia en este escenario empieza con el usuario final pisando el pedal del freno, entonces "no llega a los detalles de lo que los ingenieros tienen que conseguir".
Nuestra siguiente plantilla es ideal para este tipo de PBI.
Historias del sistema
Una historia de sistema contiene las mismas características que una historia de usuario. "Cada elemento del backlog tiene que tener una propuesta de valor, para quién es y cosas como restricciones de prueba o lo que llamaríamos criterios de aceptación", afirma Avi. La historia del sistema se centra más en un proceso específico.
Esta es la fórmula básica:
<Action verb> <Subject> De modo que <Who> consigue <What> o <Goal> se consigue.
El enfoque de una Historia del Sistema es una acción concreta que debe llevarse a cabo para lograr el efecto deseado.
Sí, la diferencia es matizada pero importante.
Avi explica la diferencia con este ejemplo de una de las empresas de bienes de consumo envasados con las que ha trabajado.
"Digamos, por ejemplo, que tienes un equipo haciendo una cerveza. Y quieren hacer una cerveza ligera. Así que tienen que disminuir el contenido de alcohol o ABV ". Una historia de usuario para este escenario puede decir: "...".Como bebedor de cerveza light, me gustaría una cerveza con menos alcohol por volumen para consumir menos calorías".
"Eso está muy bien", dice Avi, "pero no explica lo que tienen que hacer los trabajadores de la fábrica de cerveza".
Una Historia del Sistema iría directamente al grano. "Es mejor decir, correr la cerveza en el tanque tres a través del evaporador para que se consigue un ABV más bajo"(negrita añadida para ilustrar los elementos de la fórmula de la historia del sistema).
Una forma sencilla, clara y eficaz de asegurarse de que se completan los pasos para abordar un problema con una solución conocida. Ese es el objetivo de una Historia del Sistema. Necesitamos que se haga esta cosa en concreto.
Puntos fuertes de una historia del sistema
La claridad y el reconocimiento de que a veces los sistemas son los propios usuarios finales. Y que no todo el trabajo importante se hace pensando en un humano. Las Historias del Sistema también son perfectas para el trabajo que debe cumplir requisitos internos.
Además, el formato es mucho más fácil de escribir que la clásica historia de usuario.
Debilidades de una historia del sistema
La debilidad aquí es el hecho de que las Historias del Sistema bien pueden dictar exactamente lo que el equipo necesita hacer para lograr un PBI. Como señala Avi, esto puede reducir la innovación. "Siempre habrá un equilibrio entre las limitaciones y la innovación.
Aflojar las restricciones, aumentar la innovación". System Stories, añade Avi, significa que "estamos aplicando un poco más de práctica de restricciones para esa función".
Historia del trabajo
Esta plantilla PBI nació del trabajo de Anthony Ulwick y su libro Tareas pendientes. Se centran en la motivación. No en lo que quiere el usuario final, sino en lo que quiere conseguir. Y "contratan" herramientas para conseguirlo. 
suceder. "Nadie va a la ferretería porque quiera una broca de un cuarto de pulgada", explica Avi, "compran una broca de un cuarto de pulgada porque necesitan un agujero de un cuarto de pulgada". Por lo tanto, las Historias de empleo se centran en la motivación más que en las personas.
Su formato es el siguiente:
En <Situation> Quiero <Motivation> para que pueda <Expected Outcome>.
La idea de una historia de trabajo, dice Avi, "es que nos fijamos en lo que la persona está tratando de lograr mediante el empleo de nuestro producto".
Este enfoque sirve tanto para PBI individuales como para epopeyas de PBI.
Puntos fuertes de una historia laboral
Las historias de trabajo son una forma excelente de crear PBI para productos o servicios utilizados por una gran variedad de personas. Sin embargo, su enfoque en la motivación y el logro de un resultado esperado mantiene al usuario final en mente. Las Historias de Trabajo son tan flexibles como las Historias de Usuario en el sentido de que pueden ser utilizadas tanto para PBIs individuales como para epopeyas.
Debilidades de una historia laboral
El principal punto débil de una historia de empleo es que no se hace hincapié en la persona. Por eso Avi aconseja volver a centrarse en las personas cuando se abordan diferentes casos de uso de un producto o servicio.
"Tomemos el concepto de usuario avanzado de un programa", dice Avi, "son una persona muy diferente de un usuario estándar. Los usuarios avanzados son más exigentes, quieren más funciones y utilizan un programa de una forma que la mayoría de nosotros nunca haremos". La motivación de un usuario avanzado, afirma, "es muy diferente. Así que hay que volver a tener en cuenta a esa persona en el momento adecuado para asegurarse de que se le está aportando valor".
¿Y si no hay ninguna plantilla?
Las plantillas PBI pueden ser herramientas poderosas. Pero son sólo eso, una herramienta. Y como ocurre con todas las herramientas, sólo deben emplearse cuando su uso sea beneficioso. En otras palabras, su uso no es obligatorio. Si usted y su equipo funcionan mejor con PBI que no se ajustan a ninguna plantilla, no los utilice.
Avi subraya, sin embargo, que sigue habiendo cinco características que debe tener un PBI bien redactado para transmitir todo el contexto necesario para que el equipo ofrezca un resultado alineado con el valor en el trabajo solicitado. 
- Propuesta de valor
- Receptor de valor
- Medidas necesarias
- Restricciones
- Criterios de la prueba
No tenga miedo de mezclar y combinar el formato de sus PBIs. Un Product Backlog puede estar compuesto por Historias de Usuario, Historias de Sistema, Historias de Trabajo e historias sin plantilla. Cuando su objetivo esté claro, elija la plantilla que funcione mejor para usted y su equipo para cada PBI.
También dNo se sienta limitado por los formatos. No te ates a ti y a tu equipo intentando escribir algo de una forma que no tiene sentido. Elija la herramienta adecuada para cada trabajo. Para cada trabajo. Cada vez.
Vea la conversación completa para saber más sobre cada una de estas plantillas de PBI y escuchar ejemplos de su uso.
Este post es parte de nuestra serie ScrumCast de conversaciones con líderes de opinión que han ayudado con éxito a transformar organizaciones y potenciar equipos e individuos. Cada episodio explora la Agilidad organizativa y los patrones, tácticas y técnicas Scrum que impulsan el éxito en el mundo real. Suscríbase a nuestro canal de YouTube para ver los últimos episodios de ScrumCast.
Spanish 
English 
French