Para sacar el máximo rendimiento a una sesión en la que se está trabajando con el product owner en la definición de historias de usuario o requisitos, lo mejor es centrarnos en unos temas concretos y que tanto él como nosotros no terminemos saturados con un exceso de información.
Si se tienen estudiados y trabajados con anterioridad a la sesión, mucho mejor, ya que se partirá con una base que permitirá ser mucho más efectivo, aún cuando se descarte la solución o soluciones que se hayan pensado. No se trata de acertar a la primera, se trata de ir trabajando en la definición.
El exceso de información es difícil de procesar durante y después (sobre todo cuando se trata de aspectos de negocio o técnicos que tienen una cierta complejidad) y aunque pueda permitir delimitar el alcance de una serie de historias de usuario, nos daremos cuenta después de que hay una gran cantidad de detalles que se nos han escapado y es en esos detalles donde se encuentra realmente la clave para cumplir o no las expectativas del usuario.
¿Dónde está el límite? Cuando ya llevas trabajando un tiempo con el product owner y con tu equipo, sabrás donde tienes que poner el listón.
También es importante tener en cuenta la frecuencia con que podemos reunirnos con el product owner. Si está poco accesible y el proyecto tiene un ritmo medio o alto, es normal y casi necesario que pese a que no sea la mejor solución, tratar de aprovechar las sesiones para obtener toda la materia prima posible.
Esta circunstancia no es deseable ya que el nivel de implicación del product owner debe ser alto y como poco debe ajustarse a lo que el proyecto necesita.
Otro aspecto a tener en cuenta es el nivel de madurez de las historias de usuario con la que estás trabajando.
Cuando se trabaja en un módulo o en un subsistema nuevo y no se sabe por dónde empezar (ni usuarios, ni nosotros), no es malo poner sobre la mesa, las ideas generales que se tienen del mismo y en sesiones posteriores tratar de ir profundizando en aspectos concretos.
Es importante partir de esa visión general, aunque se tarde más de lo que nos gustaría en tenerla, ya que sirve como esquema para usuarios y desarrolladores, de lo contrario se corre el riesgo de que empecemos a desarrollar demasiado pronto y cuando hayamos completado un buen número de historias, el usuario se de cuenta de que las piezas no encajan y que eso no es lo que quiere o cómo lo quiere.
No hace falta, no es necesario, no es ágil, la especificación detallada porque cuando empecemos a desarrollar surgirán inevitablemente cambios, pero tampoco es bueno empezar casi a ciegas.
Jummp 