Historias de usuario, cuéntalas no las escribas!

Las historias de los usuarios a menudo se malinterpretan como  “requisitos ligeros” , dados por los stakeholders de negocio al equipo de desarrollo.

Este malentendido conduce a que se recojan historias en una herramienta de gestión de tareas, con un montón de detalles escritos por la gente de negocio.

Excepto en algún caso muy extraño de que el representante comercial sea también un experto técnico y tenga una gran visión del producto, esta división del trabajo impide que las organizaciones obtengan los beneficios reales de las historias de los usuarios.

Para dejar las cosas muy claras, si un equipo recibe pasivamente documentos en una entrega, independientemente de cómo se les llame y de si están en papel, en un wiki o en un sistema de tickets, eso no funciona realmente con las historias de los usuarios.

Las historias de usuario implican un modelo completamente diferente: requerimientos por colaboración.

La transferencia de información se sustituye por un modelo de participación y conversaciones frecuentes.

Cuando el dominio y los conocimientos técnicos se difunden entre diferentes personas, la conversación entre los stakholders de negocio y los equipos de entrega a menudo conduce a buenas preguntas, opciones y ideas de productos.

Si los requisitos son simplemente escritos y entregados, esta discusión no sucede.

Incluso cuando estos documentos se denominan historias, para cuando un equipo los recibe, todas las decisiones importantes ya se han tomado.

Las Historias de Usuario en Scrum

contando historias de usuario

Las discusiones eficaces sobre las necesidades, requisitos y soluciones de los usuarios adquieren una importancia crítica con fases de entrega cortas, porque  no hay tiempo suficiente para que nadie se siente y documente todo .

Por supuesto, incluso con fases de entrega más largas documentando todo esto en raras ocasiones funciona, pero la gente a menudo mantiene una pretensión de hacerlo.

Con las fases de entrega medidas en semanas o días, no hay suficiente tiempo ni siquiera para fingir.

Cuando una sola persona está escribiendo y documentando historias detalladas, toda la carga del análisis, comprensión y coordinación recae sobre esa persona.

Esto no es sostenible con un rápido ritmo de cambio, y crea un cuello de botella innecesario. En esencia, toda la cadena se mueve a la velocidad de esa persona, y ella siempre está demasiado ocupada.

En Conclusión

Trate de contar historias en lugar de escribir detalles. Involucrar a las partes interesadas del negocio y a los miembros del equipo de entrega en una discusión, analizar una historia desde diferentes perspectivas y explorar opciones.

Esa es la forma de descubrir los beneficios reales de trabajar con historias de usuarios.