Reuniones de refinamiento que no sirven para nada (y cómo arreglarlo)
El refinamiento es potencialmente una de las actividades más valiosas en equipos ágiles. En la práctica, muchas sesiones son una hora de tiempo colectivo que no aporta nada. La diferencia está en cómo se preparan.
He estado en reuniones de refinamiento donde el resultado neto era que todos salíamos con menos claridad de la que teníamos antes de entrar. Preguntas sin respuesta, historias a medias, debates sobre detalles de implementación que no llevaban a ningún lado.
También he estado en sesiones de refinamiento donde una hora de trabajo colectivo generaba un nivel de alineación y comprensión del problema que habría costado días de trabajo asíncrono. La diferencia no era el equipo. Era la preparación.
Por qué fallan tantas sesiones de refinamiento
El error más común es llevar ítems al refinamiento sin el trabajo previo mínimo. Un título de historia de usuario y dos líneas de descripción no son suficiente para que un equipo pueda estimar, preguntar las preguntas correctas, o identificar las implicaciones técnicas.
El resultado es que la primera mitad de la sesión se gasta en entender qué se está discutiendo, la segunda mitad en preguntas que el PM no puede responder porque no ha hecho el trabajo de discovery previo, y al final se pospone la historia para “la próxima sesión”. Y en la próxima sesión ocurre exactamente lo mismo.
El segundo error es no distinguir entre refinamiento de problema y refinamiento de solución. Refinar una historia para la que no se ha validado el problema subyacente es una pérdida de tiempo. Si hay duda sobre si el problema merece ser resuelto, esa conversación tiene que ocurrir antes del refinamiento, no durante.
Qué necesita estar listo antes de la sesión
Para que el refinamiento funcione, el PM necesita llegar con:
El problema del usuario articulado. No la solución, el problema. Quién lo tiene, con qué frecuencia, qué hace actualmente para resolverlo y por qué esa solución actual no es suficiente.
La hipótesis de solución con suficiente detalle. No un spec completo. Suficiente para que el equipo técnico pueda hacer preguntas de implementación y el equipo de diseño pueda visualizar el flujo.
Los criterios de aceptación mínimos. Qué tiene que ser verdad para considerar esta historia completada. Sin esto, el equipo no puede estimar con ningún nivel de confianza.
Las restricciones conocidas. Si hay restricciones técnicas, de negocio o de diseño que afectan a la solución, el PM tiene que traerlas. Si el equipo las descubre durante la sesión, el tiempo se gasta en resolver restricciones en lugar de alinear sobre la solución.
Lo que el equipo debería poder hacer en la sesión
Con esa preparación, el refinamiento tiene un propósito claro: que el equipo técnico pueda hacer las preguntas que necesita para entender el alcance completo, que diseño pueda validar que el flujo propuesto tiene sentido, y que al final de la sesión todos puedan estimar con un nivel razonable de confianza.
Las preguntas del equipo técnico son valiosas precisamente porque revelan las partes que el PM o el diseño no han pensado. “¿Qué pasa si el usuario no tiene permisos para hacer esta acción?” “¿Cómo se comporta esto en modo offline?” “¿Hay impacto en las notificaciones existentes?” Esas preguntas pueden generar criterios de aceptación adicionales o ajustes en el diseño que es mucho mejor descubrir en la sesión de refinamiento que durante el desarrollo.
El indicador de una sesión que ha funcionado
Al final de una buena sesión de refinamiento, todos los participantes deberían poder responder con seguridad a estas tres preguntas:
¿Qué problema resuelve esta historia?
¿Qué tiene que ser verdad para que la consideremos terminada?
¿Hay algo que no sabemos que necesitamos descubrir antes de empezar a construirla?
Si alguien sale de la sesión sin poder responder alguna de estas preguntas, la historia no está lista. Y meter una historia no lista en un sprint genera deuda de decisiones que se paga durante el desarrollo, normalmente con interrupciones, cambios de alcance y frustración por ambas partes.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.