Como Product Owner seguramente te has preguntado la importancia de las Historias de Usuario y cómo aprender mejores estrategias para no sólo crearlas, sino darles seguimiento y perfeccionarlas. Las Historias de Usuario muchas veces se malinterpretan como requisitos ligeros proporcionados por los Stakeholders para el equipo de desarrollo, pero hoy te traemos una serie de tips para mejorar la aplicación de estas.

UN PEQUEÑO MALENTENDIDO:

Generalmente hay un error que lleva a interpretar nuestras historias de usuario en una herramienta de gestión de tareas, con un montón de detalles escritos por representantes comerciales a excepción en el muy raro caso en el que el representante comercial también es un experto técnico y tiene una gran visión del producto. Esta división de trabajo impide que las organizaciones aprovechen los beneficios de las Historias de Usuario.

PARA ACLARAR LAS COSAS:

Si un equipo recibe documentos constantemente para después trabajar con ellos, independientemente de cómo se llamen y de si están en papel, en una fuente de información o en un sistema de etiquetado, no funcionarán como las Historias de Usuario. Las organizaciones con este proceso no obtendrán los beneficios completos de la entrega iterativa.

Las Historias de Usuario implican un modelo completamente diferente: requisitos por colaboración. Las entregas de documentos son reemplazadas por la participación frecuente y las juntas. Cuando el dominio y el conocimiento técnico se distribuyen entre diferentes personas, las juntas entre los Stakeholders y los equipos de entrega generalmente conduce a buenas preguntas, opciones e ideas sobre el trabajo realizado. Si los requisitos solo se escriben y se entregan, esta junta no tendría objeto alguno. Incluso cuando tales documentos se llaman historias, cuando un equipo los recibe, ya se han tomado todas las decisiones importantes.

 Las juntas efectivas sobre las necesidades, los requisitos y las soluciones de los usuarios adquieren una importancia crítica con fases de entrega cortas, porque simplemente no hay tiempo suficiente para que nadie se siente y documente todo. Por supuesto, incluso con fases de entrega más largas, documentar todo rara vez funciona, pero las personas a menudo mantienen la pretensión de hacerlo. Con las fases de entrega medidas en semanas o días, no hay tiempo suficiente para asumir la tarea.

Cuando una sola persona está escribiendo y documentando historias detalladas, toda la carga del análisis, la comprensión y la coordinación recae en esa persona. Esto no es sostenible con un rápido ritmo de cambio y crea un cuello de botella innecesario y entorpecedor. En esencia, todo el seguimiento y continuidad se mueve a la velocidad de esa persona, y siempre se estaría sobrecargado de trabajo.

TRATA DE CONTAR HISTORIAS EN LUGAR DE ESCRIBIR DETALLES:

Usa tarjetas de historia físicas, sistemas de tickets electrónicos y herramientas para la gestión del Backlog solo para recordar las conversaciones de las juntas, no pierdas mucho tiempo afinando los detalles por adelantado. Involucra a los Stakeholders y miembros del equipo de entrega en una junta, mira una historia desde diferentes perspectivas y explora las opciones. Esa es la manera de desbloquear los beneficios reales de trabajar con historias de usuario.

BENEFICIOS CLAVE:

Las juntas nos permiten a los representantes de negocios (Product Owner) no sólo explicar lo que quieren, sino también asegurar que los miembros del equipo de desarrollo lo entienden correctamente. Los malentendidos entre diferentes roles son un problema importante con cualquier tipo de entrega. Explicar una historia cara a cara impide que los problemas caigan a través de brechas de conocimiento.

El segundo beneficio es un análisis más rápido. Cuando todo el equipo está involucrado en una junta, las brechas funcionales, las inconsistencias y los requisitos confusos se descubren más rápido que cuando una sola persona necesita anotar los detalles.

El beneficio más importante de las discusiones en comparación con la entrega es que producen mejores soluciones. Para poder diseñar buenas soluciones, la gente necesita conocer los planes de negocio y las oportunidades, entender el dominio del problema, tener un conocimiento profundo de las limitaciones técnicas y una conciencia de las nuevas tecnologías potenciales. La participación de un grupo de personas en el análisis desde diferentes perspectivas ayuda al equipo a beneficiarse de los conocimientos compartidos.

CÓMO HACER QUE FUNCIONE:

Hay varias razones comunes para escribir historias detalladas. La mayoría de estas necesidades se pueden cumplir sin entregar documentos. Estas son las excusas más comunes:

Cuando los requisitos reglamentarios o el entorno político requieren una aprobación formal, los detalles escritos sirven como un registro de lo que fue aprobado.

Cuando diferentes partes interesadas del negocio tienen que acordar o aprobar planes, tener algo escrito para enviar es útil. Las organizaciones geográficamente distribuidas a menudo tienen esta necesidad.

Si las historias dependen del conocimiento especializado de las personas que no están disponibles para participar en las discusiones de la historia, los detalles escritos son una buena manera de transferir sus conocimientos.

Cuando las dependencias de terceros o los sistemas involucrados requieren análisis e investigación que consumen mucho tiempo, implicar a todo el equipo en eso sería una pérdida de tiempo. Los detalles escritos son una buena manera de capturar los resultados de la investigación.

La excusa más común para entregar documentos es insistir en la aprobación formal del alcance. Sin entrar en si la aprobación formal es correcta o incorrecta, si debes tenerlo, posponer la firma hasta después de las discusiones de la historia. Consigue que cada historia sea firmada mientras la discutes. Hemos trabajado con varios equipos en entornos regulados donde el debido proceso exigió que un sponsor empresarial aprobara el ámbito. En tales casos, los Sponsors de negocio han firmado las especificaciones con ejemplos producidos como resultado del refinamiento de la historia y discusiones de análisis.  

 Si el alcance final tiene que ser aprobado por varias partes interesadas del negocio, agenda la conversación algunos días antes de comenzar a poner en ejecución una historia oficialmente, y después coordina con las partes interesadas. Por ejemplo, un equipo con el que trabajamos en una compañía de seguros necesitaba obtener los detalles aprobados por todos los gerentes del país, por lo que discutieron historias una semana antes de la iteración. Su Product Owner recogió entonces los resultados de las discusiones, los refinó en especificaciones y los envió a todos los Stakeholders para estar de acuerdo.

Los equipos efectivos con dependencias de terceros, o aquellos que dependen de conocimientos especializados externos, generalmente dedican a una o dos personas a investigar esas dependencias una o dos semanas antes de comenzar una historia. Los resultados de las investigaciones son un gran punto de partida para las discusiones de análisis de historia.

Algunos equipos analizan las historias dos veces como grupo: una o dos veces por semana antes de la iteración para recopilar preguntas abiertas y enfocar la investigación inicial y la segunda vez justo por delante de la iteración para comunicarse y ponerse de acuerdo sobre los detalles. En tales casos los detalles a menudo se recogen con la misma herramienta de gestión de tareas y de historias, pero los equipos los tratan sólo como notas para iniciar una junta, no como requisitos formales para el inicio de sesión.