Cuando creamos HU por y para todo

En este post quiero compartirles lo fácil que puede ser que un equipo pierda foco y valor de lo que está haciendo, mal entendiendo lo que significa una historia de usuario.

Las historias de usuario están pensadas como pequeñas partes de valor al producto que se está construyendo por lo tanto cada historia que pase a producción o release tiene que ser eso, una entrega de valor, un incremento.

Las historias de usuario deberían ser descripciones breves y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema.

Mike Cohn

Pero tengo la experiencia de llegar a un equipo que tenía más de 2 años trabajando en célula ágil, era un equipo SCRUM, y siempre que llego a un equipo me tomo la primera semana como observador para ver la cultura de ese equipo, pienso que eso es importante antes de llegar a proponer nuevas prácticas o ideas de mejora. Y lo primero que observe en este equipo fue que en su Sprint Product backlog, TENIAN HU PARA TODO, literalmente para todo!!, como ejemplo: HU para gestión de paso a producción, HU para reuniones, HU para apoyo a otras células agiles.

Esto es una práctica que se ve en algunos equipos, que tienen la necesidad de demostrar o justificar todo lo que hacen en la célula ágil, si bien es cierto, tenemos que dejar que el equipo experimente, madure y evolucione en las cosas que les hace bien en pro de lograr la auto organización y la dependencia de ellos mismos. Tenemos que ayudarlos a ver que esto no es justificación del día a día y que el tablero que usemos Kanban o Scrum no significa poner ahí todo. Significando un seguimiento y de identificación de que miembro del equipo hace más trabajo o HU en una iteración.

Estos framework, siento yo, no fueron pensados para eso, sino más bien para evidenciar el valor que se entrega en cada iteración orientado netamente al producto en cuestión, por esa razón, y volviendo al ejemplo. No es necesario escribir HU para indicar o demostrar en que estuve trabajando o que estuve haciendo durante el día convirtiendo el framework en una herramienta más de seguimiento a los desarrolladores que de muestra de valor que se entrega.

En conclusión lo que propuse en este equipo en complicidad con el PO, siendo esta otra historia que me gustaría contar en un futuro post, que se crearan solo HU relacionadas al producto, entendiendo que los pasos a producción son parte de la Historias de Usuario, entonces que se definió:

  • Se crean como primera regla para una HU, criterios de aceptación.
  • Se crearon nuevos acuerdos de DOR y DOD.   
  • Y para comentar estas “actividades extras”, se acordó mencionarlas en las dailys del equipo.

Si se dan cuenta son cosas básicas que debería tener un equipo ágil, y que aunque lleven meses o años siempre es necesario conversar y acordar nuevos acuerdos para hacer ver que las cosas que estamos haciendo aún se pueden mejorar y hacer mejor. Por qué después de todo de eso se trata la mejora continua, o no?


Deja un comentario