Refinamiento de requerimientos (grooming)

Si están trabajando con metodologías agiles como Scrum, Kanban u otra, tal vez hayan oido el término refinamiento de requerimientos o grooming, en caso de que no, hoy voy a hablarles de lo que para mi significa esto ya que es una de las ceremonias más importantes en agile y personalmente me gusta bastante, es la reunión donde el equipo de trabajo entiende y recibe los requerimientos escritos por parte del dueño del producto (product owner) o la persona encargada de los requerimientos y se levantan riesgos, retos y funcionalidad pendiente o no estimada.

Se le puede llamar refinamiento, grooming o como se quiera, pero esta ceremonia es bastante importante, si me lo preguntan a mi, para equipos pequeños o medianos, todas las personas del equipo deben estar en el refinamiento de requerimientos, todos los puntos de vista son y deben ser válidos y todos pueden tener diferentes perspectivas sobre alguna funcionalidad o requerimiento, he tenido la oportunidad de ver como miembros junior o mid level del equipo tienen opiniones y casos faltantes en alguna historia que arquitectos o personas senior no tuvieron en cuenta en el momento de refinar los requerimientos, por eso me gusta que todos los miembros del equipo estén en la reunión y por supuesto, que participen en ella. Sé que esto es dificil porque el tiempo invertido en reuniones es tiempo no invertido en trabajo del proyecto y en progreso del mismo, pero esta reunión tiene mucha importancia y el impacto que tiene agrega mucho valor, es conocer antes de empezar a desarrollar, que se va a hacer y tener una idea muy pequeña de como puede que se haga. Para equipos grandes o proyectos muy grandes todo cambia, se pueden tener diferentes equipos enfocados en diferentes áreas o módulos o se neesitaría que todos los líderes por disciplina (QA, front end, back end, etc) hagan este refinamiento y estimen las historias.

El propósito más importante del refinamiento de requerimientos es, como su nombre lo indica, refinar la funcionalidad e identificar escenarios faltantes, criterios de aceptación no tenidos en cuenta inicialmente o casos aislados de funcionalidad que el dueño del producto no pensó al momento de crear la historia o requerimiento, la idea es dejar la historia tan clara y específica como sea posible para no tener cabos sueltos. Estas reuniones usualmente toman mucho tiempo (más de una hora) y el tiempo invertido debe ser valioso, he visto reuniones en las que los miembros del equipo van a crear las historias de usuario o requerimientos y no a refinarlos, esto no es correcto y desde mi punto de vista, la reunión de refinamiento debe ser reagendada hasta que las historias de usuario sean creadas. Por supuesto, la discusión es un punto clave en esta ceremonia y puede tomar mucho tiempo, si esto pasa, una nueva sesión de refinamiento debe ser agendada, la reunión debe terminar cuando todas las historias de un sprint o fase hayan sido refinadas y estimadas. Quiero resaltar que las discusiones técnicas sobre como hacer las cosas no deben ser parte de estas reuniones, la reunión es enfocada al que se va a hacer, no al como se va a hacer, el como es algo interno y va después, asi que intenten no entrar en discusiones técnicas profundas o el tiempo consumirá la reunión y no se habrán estimado muchas historias.

Otra parte del refinamiento es la estimación de las historias, esto puede hacerse de muchas formas, la más común que he visto en mi experiencia es la de puntos de historia usando la secuencia de Fibonacci(1, 2, 3, 5, 8, 13, etc), entre más grande el número, más compleja es la historia y aquí, la experiencia toma un valor importante, puede haber personas que ya hayan hecho una historia o requerimiento similar en el pasado y piensen que una historia compleja no debe ser estimada con un número alto, sin embargo esto puede ser un arma de doble filo porque puede impactar las entregas del proyecto, por ejemplo, una historia de 8 puntos que fue estimada con 3 o 5 puntos puede no ser entregada al final del sprint porque no se estimó correctamente. Finalmente, he visto personas que no estiman la historia o requerimiento como un todo sino solo el esfuerzo que la persona le va a invertir (solo desarrollo, solo diseño, etc) pero no el trabajo o impacto de todas las disciplinas, aquí es donde QA debe entrar en acción, QA tiene que pensar en todos los riesgos e impacto del requerimiento (áreas afectadas, integraciones complejas, esfuerzo visual, etc). He visto historias no tan complejas para desarrollar, sin embargo, el impacto de esto es que no se tiene en cuenta que QA debe probar la funcionalidad en múltiples navegadores y dispositivos móviles y que además, debe probar muchos casos tanto de éxito como de error.

Es importante tener a QA en las reuniones de refinamiento de requerimientos porque esa persona va a ser la que probará la funcionalidad y actuará como usuario final antes del cliente, muchas cosas pueden faltar al momento de estimar y puede que QA tenga un punto de vista más enfocado a usabilidad y funcionalidad que a temas técnicos, esto puede cambiar el estimado original de un requerimiento. Sé que a muchas personas no les gustan estas reuniones, personalmente me gustan mucho y les doy siempre la importancia que se merecen, asi que si están invitados a estas reuniones, participen y pongan mucho cuidado, cada opinión es importante.

@LuchoAgileQA