Historias de Usuario: ¿Por qué son populares y mal aplicadas?
Por Vanessa Amaya
Las Historias de Usuario se han convertido en una herramienta popular en los equipos que trabajan con marcos ágiles. Sin embargo, a pesar de su popularidad, muchas organizaciones luchan por utilizarlas de manera eficiente. Lo que he observado a lo largo de 10+ años en el mundo ágil, es que esta lucha no solo es alrededor de técnicas para crear historias y aprovecharlas, también tiene que ver (y mucho) con aspectos culturales alrededor de hábitos de captura y especificación de solicitudes y “requisitos”.
El Concepto de las Historias de Usuario
Las Historias de Usuario son descripciones simples de una funcionalidad desde la perspectiva del usuario final. El concepto de Stories, nos llegó de la mano del marco ágil eXtreme Programming.
La estructura de una Historia es simple, de cada característica del producto o cada parte de lo que estamos creando se especifica el QUÉ, el PARA QUIÉN y el PARA QUÉ de la siguiente forma:
Como <tipo de usuario>
Quiero <característica o funcionalidad>
Para <beneficio esperado>
Y le agregamos criterios de aceptación, que son condiciones que nos permiten crear la característica o funcionalidad correcta y validar que así sea. Son las condiciones que nos permiten crear con la calidad esperada. Los criterios de aceptación ayudan a dar claridad sobre las expectativas de cada parte del producto para que evitemos lo más posible el “eso no era lo que se esperaba”.
Lo anterior no es complejo de entender, lo complejo es que es más fácil pensar en bloques grandes y especificar de esa manera pero al momento de entender y crear, será difícil. Las historias de usuario FACILITAN:
El entendimiento de quienes van a hacer realidad el producto o entregable.
Abstraer la información necesaria para construir con la claridad que nos lleva a la calidad.
Entender las partes de la solución.
Malas Prácticas en la Especificación
Historias Demasiado Grandes: Un error común es crear historias demasiado grandes, conocidas como épicas, sin desglosarlas en partes manejables. Esto puede hacer que sean difíciles de completarlas ya que para el equipo que hace realidad el producto es más difícil abstraer las partes de la solución para hacerlas realidad y también hace que pueda haber más probabilidad de malos entendidos.
Esto de que a las historias demasiado grandes se les conozca como épica, es porque al final de cuentas, estas historias grandes surgen inevitablemente creo que era mejor ponerles un nombre.
¿Por qué no evitamos las épicas y nos vamos directo a hacer Historias?
Porque la manera natural de descubrir las partes de un producto es de lo general a lo particular, es decir, llegar directo a identificar las partes de la solución, no es natural, lo orgánico es ir identificando objetivos, partes macro de la solución y ya de ahí podemos identificar sus detalles.
Criterios de Aceptación Incompletos o ineficientes: No definir criterios de aceptación claros puede llevar a ambigüedades sobre cuándo se considera que la historia está terminada, lo que puede afectar la calidad del producto.
Otras razones que pueden llevar a la ineficiencia en los criterios de aceptación son:
Solo considerar los escenarios positivos y omitir los casos de borde o escenarios negativos puede resultar en funcionalidades o características que fallan bajo ciertas condiciones. Es importante incluir criterios para situaciones en las que la funcionalidad no debe cumplir.
No incluir a los usuarios finales o stakeholders en la creación de los criterios de aceptación puede resultar en criterios que no reflejan sus necesidades o expectativas. La colaboración con todas las partes interesadas es crucial para el éxito.
Incluir demasiados detalles técnicos en los criterios de aceptación puede desviar el enfoque del usuario final y complicar el entendimiento para los equipos no técnicos. Los criterios deben centrarse en el comportamiento observable y los resultados esperados desde la perspectiva del usuario.
Enfoque Técnico: Redactar historias desde una perspectiva técnica en lugar de centrarse en el usuario puede desviar el propósito de las historias y hacerlas menos efectivas. Muy probablemente vas a encontrar en libros, blogs o en prácticas organizacionales el concepto de “Historias Técnicas”. Creo que es importante comprender que un Backlog no solo tiene Historias de Usuario, no a todo le necesitamos llamar una Historia, y es así como los equipos que obtienen sus requisitos o elementos técnicos derivados de lo que se les pide quieren que aparezcan en el Backlog y le llaman Historias, pero desvirtúa el objetivo. Ya que un requisito técnico aunque será de beneficio para el usuario, el usuario no lo va a pedir, el negocio no lo va pedir directamente, el Product Owner no sabría como identificarlo. Es el equipo quien si debe de poner en el Backlog todo trabajo que se derive de lo que se le solicita directamente pero no tiene por qué ser una Historia.
Historias Vagas: Descripciones incompletas o vagas pueden dejar demasiadas interpretaciones abiertas, complicando el desarrollo/creación y las pruebas/validación. Este tipo de historias son un síntoma de que no se comprende el objetivo, ni se ha aprendido cómo hacerlas o que solo se toman en cuenta como trámite.
Reflejar en la Historia quien la solicita en lugar de referirse al usuario o consumidor: Tal vez has visto más de una historia que inicia diciendo “Como Product Owner lo que necesito es….” y de ser así, es un síntoma de que no se está poniendo al usuario o consumidor en el centro de las decisiones, también puede ser que quien funge como Product Owner o quien sea responsable de crear las historias no tenga conocimientos sobre el objetivo de crearlas y las hace como solicitudes. Es común confundir al cliente final con el cliente solicitante, es decir, quien pide los requisitos no siempre es el usuario final. Esto causa errores en las historias de usuario, mencionando al Product Owner o solicitante, en lugar de enfocarse en quien realmente lo necesita.
Aspectos Culturales en la Captura de Especificaciones
La manera en que una organización maneja la captura de “requisitos” está profundamente influenciada por su cultura. Aquí algunos aspectos culturales que pueden afectar el uso eficiente de las Historias de Usuario:
Llamarle “requisitos” o “requerimientos”: Empezando porque en el mundo empresarial hicimos un refuerzo en estas palabras, palabras que dan una connotación de obligatoriedad y entonces, cuando algo tiene esta connotación pues dificulta el conversarlas, aterrizarlas, analizarlas, priorizarlas porque sin importar lo que se haga, son obligatorias. La cuestión es que dentro del mundo empresarial sigue siendo uno de los mayores problemas el cómo especificamos el trabajo, traemos debilidades de análisis por la prisa de ejecutar sin aterrizar bien las ideas. Para romper esto, la agilidad propone les llamemos ahora “elementos de trabajo”, quitándole así ese sabor a obligatoriedad y poder reflexionar continuamente nuestra carga de trabajo para mantener una justificación continua de valor y romper el “hacer por hacer”.
Comunicación débil: Una cultura que promueve la comunicación abierta y la colaboración es crucial. Los equipos deben sentirse cómodos compartiendo ideas y discutiendo las historias por un lado, por otro lado, durante muchos años nos hemos acostumbrado a hablarnos a través de documentos en lugar de hablarnos directamente y tanta documentación ha hecho que la percibamos como documentos por trámite. El reto mayor de las historias es que no son un documento ni su objetivo es la especificación, las historias de usuario son un medio muy bueno para CONVERSAR, ENTENDER Y PRIORIZAR.
No Involucrar a los Stakeholders: No involucrar a usuarios reales o stakeholders puede resultar en elementos de trabajo que no reflejan sus verdaderas necesidades. La participación activa de todos los interesados es esencial para el éxito.
Falta de Adaptabilidad: La flexibilidad para ajustar las historias a medida que se obtiene nueva información o cambian las necesidades es vital. Las organizaciones rígidas pueden luchar con esta adaptabilidad pero al final el beneficio tan grande debería de ayudarles a ganar esa lucha a través de incluir prácticas Descubrimiento contínuo y Análisis colaborativo de manera constante.
No hay Capacitación Continua: Promover la capacitación y el aprendizaje continuo sobre las mejores prácticas en la creación de Historias de Usuario puede ayudar a evitar errores comunes y mejorar la eficiencia. Muchas veces la creencia de que por que algo es fácil de entender va a ser fácil de llevar a cabo. Esto pasa cuando olvidamos que no solo es el concepto, es el contexto en el que trabajamos en el que ese concepto se quiere habilitar.
Hacer especificaciones enfocadas a facilitarle el trabajo a quienes especifican cuando el verdadero objetivo es FACILITARLE EL TRABAJO A QUIENES HACEN REALIDAD ESAS ESPECIFICACIONES. Si, es más difícil hacer Historias de Usuario que dar información incompleta, es más difícil que dar muchos documentos con información concentrada y a alto nivel para que los demás analicen y rellenen con supuestos la información. Definitivamente es más fácil que decir “todo urge” sin separar eficientemente el trabajo, porque, generalmente quien dice “Todo urge” no es la misma persona que tiene que hacer realidad el trabajo (se tenía que decir y lo dije). Hacerle más fácil el trabajo al que especifica no ayuda en nada, solo obstaculiza el trabajo y se crea una fuente incontenible de retrabajos y retrasos.
Las Historias de Usuario son una herramienta poderosa, pero su uso eficiente requiere no solo buenas prácticas de especificación, sino también una cultura organizacional que fomente la comunicación, la colaboración y la adaptabilidad. Al abordar ambos aspectos, las organizaciones pueden mejorar significativamente la captura de requisitos y, en última instancia, la calidad del producto final.
Las Historias de Usuario son un medio que fortalece la comunicación y el entendimiento.
Las Historias de Usuario, no solo son una forma de aterrizar especificaciones, si se aprovechan con otras técnicas, son medios eficientes para: DIMENSIONAR, DESCUBRIR, PLANEAR Y PRIORIZAR.
Si quieres saber más de este tema, también te invitamos a leer estos otros blogs sobre el tema:
Historias de Usuario ¿cómo aprovechar sus beneficios de manera eficiente?
Ve nuestra AgileTalk grabada: ¿Por qué no funcionan las Historias de Usuario?
¡Descarga nuestro Whitepaper! Whitepapper Requerimientos & Historias de Usuario
