La historia de usuario como herramienta generadora de conversación

Photo by Marten Bjork on Unsplash

Las historias de usuario son el corazón del Product Backlog, y una herramienta básica del Product Owner. Para que generen el impacto deseado, deben tener un formato sencillo y muy centrado en las necesidades del usuario, y no en el producto o distintos roles de la organización.

Empecemos por repasar las que para mí son las dos principales características que debe tener una buena historia de usuario:

  • Son pequeñas: la base del agilismo es el desarrollo iterativo para poder obtener el máximo valor posible con el mínimo esfuerzo (mientras que en waterfall se entregaba mucho contenido después de mucho tiempo, en agile se entrega poquito, muy frecuentemente), y así ganar feedback continuo y capacidad de respuesta. El objetivo de estas iteraciones es la entrega lo más continua posible de valor al usuario. Por tanto, necesitamos historias de usuario lo más pequeñas posible sin que éstas dejen de ser funcionales (si dividimos mucho, tendremos tareas, no historias que aporten valor).
  • Son valiosas: una buena historia de usuario es valiosa para el cliente o el usuario. Parece obvio, pero a la hora de evaluar las historias de usuario que componen el Product Backlog solemos darnos cuenta de que el foco no es realmente el usuario, sino el propio producto u otros stakeholders. Para asegurar el enfoque de usuario, podemos emplear distintas técnicas (User Story Mapping, Dual Track, Mapas de Empatía, etc), o puede escribirla el mismo usuario o cliente. Aquí, en el momento de asegurar el valor de la historia, es donde entra en juego la importancia de que generen conversación entre el PO y el resto del equipo.

De hecho, esta conversación es una de las tres Cs de la “regla de las 3Cs” para describir las claves de una historia de usuario:

  • Card: esta C quiere decir que tendremos una tarjeta en la que se expresará el valor que se quiere conseguir desde el punto de vista del usuario. Esta expresión puede escribirse con la formulación “As a… I want… So that…”, donde identificaremos distintos segmentos de usuario, sus necesidades, y el objetivo o valor que obtiene al cubrir esa necesidad. Un ejemplo: “As a student, I want to be able to have all the classes of the month available online, So that I can review the content at my own pace”.
  • Conversation: las tarjetas no deben contener toda la información necesaria para desarrollar una nueva funcionalidad. Esto suele chocar mucho al principio, pero tiene un objetivo muy concreto: una historia de usuario debe generar una conversación al respecto de la visión del usuario descrita en la tarjeta, entre el Product Owner y el resto del equipo, en la que tendrá que responder a cuestiones sobre el valor de la funcionalidad, su implementación, etc.
  • Confirmation: paso final olvidado por muchos equipos, en el que se explicita la conclusión a la que se llega tras la conversación, sobre el valor de la historia y el resultado esperado tras la implementación. Es un paso natural del refinamiento del backlog, que ahorra mucho tiempo en la Sprint Planning ya que asegura que los elementos de la historia son claros y estándares para todos los miembros del equipo. Durante esta fase de la historia de usuario suelen surgir los criterios de aceptación, acordados y entendidos por el equipo para saber cuándo la historia de usuario está realmente terminada (llegar a la Definition of Done).

Por un lado, el PO es aquella persona con una visión muy clara del producto que se quiere desarrollar y es capaz de transmitir esta visión al resto del equipo. Por otro lado, la razón de ser del sprint es obtener la máxima cantidad de aprendizaje validado por los clientes, con el menor esfuerzo posible. Para asegurar que la visión del PO es correctamente transmitida al resto del equipo, y para asegurar ese mínimo esfuerzo posible, las historias de usuario se basarán en los principios del manifiesto ágil: interacciones entre individuos mejor que documentación extensiva. Este es el motivo por el que la conversación en torno a cada necesidad de usuario es absolutamente necesaria.

Por tanto, una historia de usuario no es sólo una descripción de una funcionalidad con foco en el usuario. Se trata de una potente herramienta para interactuar que permite discutir sobre el valor de los elementos del Product Backlog y acordar cuándo se ha terminado de desarrollar el contenido de la historia y cómo se confirma su implementación.