En una iniciativa reciente en la que colaboré como Agile Coach, insistí en no plagar el Product Backlog solo con historias de usuario.
¿Por qué hice eso? Al final y al cabo, cada tarea que no era una historia de usuario tenía que reformularse.
En otras palabras, que no tenía ningún valor. Creo que esto no tiene sentido, déjame explicarte por qué.
Veo las historias de usuarios como meras plantillas de gestión de productos.
Además, una historia de usuario solo es un narrativa para describir una cosa.
Al igual que una plantilla te permite pintar el mismo patrón rápidamente, una historia de usuario es una buena manera de capturar el valor del usuario sin pensar demasiado. Solo completa los espacios que muestro aquí abajo:
Como [tipo de usuario] quiero [alguna función] para que [alguna razón].
Una mera plantilla de historia de usuario
El objetivo de las historias de usuario
Las historias de usuario tienen como objetivo garantizar que adoptemos un enfoque de diseño centrado en el usuario.
Adicionalmente, las historias de usuario nos ayudan a practicar la empatía al agregar información sobre la situación del usuario.
Nos ponemos en su lugar y nos enfocamos en crear funciones que les permitan realizar nuevas tareas o aliviar los puntos débiles.
También nos permiten priorizar el trabajo de desarrollo según lo que más importa para los usuarios.
Te adjunto una video explicación para profundizar un poco más en estos conceptos.
A medida que pasa el tiempo y la agilidad de negocio se generaliza, las historias de los usuario se transforman de una herramienta útil a un estándar de facto en todas partes.
El término “Historia de usuario” ahora es casi un sinónimo de “característica” o “feature”.
Valor para el negocio, pero no para el usuario
Ninguna metodología ágil recomienda tener historias de usuarios en el product backlog. Repito, ninguna.
Extreme Programming, el origen de las historias de usuario, llena su planificación de iteraciones con historias de usuarios y pruebas de aceptación fallidas.
Scrum habla sobre características, funciones, requisitos, mejoras y correcciones
Kanban lo resume todo con el término elemento de trabajo y la gestión de flujo del mismo.
Creo que el product backlog debe contener elementos que aporten valor al negocio a nivel global, sin importar la forma.
Conclusión
Probablemente debería haber más que solo historias de usuarios en un product backlog.
Un backlog es una herramienta de ordenación que utiliza el valor comercial global como entrada principal, en lugar de solo considerar el valor del usuario.
Digo abiertamente que hay más mundo que las User Stories, y no deben usarse para todo, a riesgo de confundir a todos.
Deberíamos usarlas cuando y solo cuando se supone que un elemento agrega valor a los usuarios.
Si bien la agilidad es el arte de actuar en un entorno incierto y cambiante, está evolucionando hacia un entorno único para todos, cosa que particularmente no entiendo.
Creo que debemos tener mucho cuidado de no considerar herramientas de una metodología que funcione en todas partes ya que así nos cargamos el empirismo y la diversidad de la manera de trabajar.