Vamos primero a revisar qué dice la Guía Oficial de Scrum sobre el refinamiento

Definicion oficial del refinamiento de sprint

El refinamiento (refinement) de la Pila del Producto (Product Backlog) es el acto de añadir detalle, estimaciones y orden a los elementos de la Pila del Producto (Product Backlog). Se trata de un proceso continuo en el cual El Propietario del Producto (Product Owner) y el Equipo de Desarrollo (Development Team) colaboran acerca de los detalles de los elementos de la Pila del Producto (Product Backlog). Durante el refinamiento de la Pila del Producto (Product Backlog), se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo (Development Team). Sin embargo, los elementos de la Pila del Producto (Product Backlog) pueden actualizarse en cualquier momento por El Propietario del Producto (Product Owner) o a criterio suyo.

De la definición oficial lo fundamental a entender es que el Refinamiento NO ES UN RITUAL como así lo son el Sprint Planning, Review y otras. Tampoco obliga a que haya presente ningún rol en concreto sino que únicamente habla del equipo.

Personalmente he trabajado con muchas interpretaciones de cómo se hace un refinamiento. Empecé trabajando con Scrum sin hacer nada explícitamente que se llamara como tal. Prácticamente todo el trabajo de análisis del Backlog, estimación y demás se hacía con el equipo durante el Sprint Planning. Más tarde, en mis tiempos de consultora informática trabajando para bancos, un grupo de expertos en cada área como el arquitecto, los Product Managers, seguridad y demás rellenaban todo lo posible la información del elemento de Backlog en JIRA y el refinamiento por parte del equipo era una mera lectura de lo que ya habían refinado otros ( 0% de posibilidad de aportación por su parte, 0% ownership, 0% creatividad por parte del equipo) . En esta última etapa de trabajo en la que estoy, el equipo al completo se reúne con Product Owner, revisa el backlog, le añade información, lo aclara y lo estima. Aquí lo que nos encontramos muchas veces es que algunos miembros del equipo consideran improductivas estas sesiones de refinamiento ya que la discusión a veces se centra entre un par de personas. Otras veces surgen dudas que se necesitan aclarar e investigar y opinan que hubiera valido la pena revisarlo bien antes de que llegue al equipo. Esto último incluso, a veces, esto provoca que se salte el refinamiento de esa historia de usuario a una siguiente sesión.

A nivel de flujos de información, en la actividad de refinar detecto dos flujos principales.

1.- Análisis o incorporación de información hacia el elemento del backlog. Aquí el conocimiento del equipo junto con otras personas con información de negocio, entorno (legal, técnico, …) , arquitectura y resto de áreas confluyen junto con la creatividad del equipo en una definición de la solución técnica que hay que realizar.

2.- Difusión de la información hacia el propio equipo. El equipo necesita entender el trabajo que hay que realizar. Una buena forma de saber que el equipo conoce su alcance es mediante el ejercicio de la estimación en conjunto. Es un buen indicador de que todos tienen en la mente el mismo tipo de trabajo cuando el equipo al completo coincide en la valoración y en los criterios por los que se ha llegado a la misma. El último momento responsable en el que debería ocurrir esta difusión de información es durante el Sprint Planning, ya que es cuando el equipo se dispone a empezar su desarrollo.

¿Quién hace falta que esté presente en cada parte? En el segundo flujo está claro que debe estar todo el equipo. Si algún miembro no participa en la difusión de información es posible que no sea capaz de trabajarlo sin bloqueos cuando llegue el momento
en el sprint.
Es en la primera parte de análisis en la que no no lo veo tan claro. Si participan personas que no tienen el conocimiento para aportar información al Backlog Item, solamente escucharán discusiones entre otros miembros hasta llegar a la solución final. No digo que esta discusión no pueda aportarles información a estos miembros del equipo más junior y veo importante que puedan colaborar para conseguir ownership del producto por su parte. Sin embargo, dependiendo del nivel de maduración de cada uno dentro del equipo , puede haber otras formas más eficientes de conseguir estos mismos objetivos que sentándose juntos sólo a escuchar.

Mi propuesta es la participación de miembros de forma incremental y con un ángulo que depende de la maduración del equipo.
En equipos pocos maduros donde hay un líder que tiene mucho conocimiento, habrá mucho trabajo de análisis por su parte y este ángulo de colaboración hasta llegar a todo el equipo sería más cerrado. En equipos muy maduros, las fases de análisis y difusión se hacen de forma simultanea y eficiente, ya que todos pueden aportan a la solución y se enteran a la vez de qué hay que hacer. Aquí el ángulo sería muy abierto o casi inexistente.

Dentro de estas dos formas opuestas también hay matices o grises. Quizá los miembros que son más seniors hacen el análisis y después se revisa con el resto del equipo. Quizá puede empezar el Tech Leader con Product Owner y preparar un esbozo de la solución que se afine con el resto.
Independientemente de cómo se haga, veo importante,de vez en cuando, si se hace una sesión de refinamiento de equipo, evaluar cómo consideran los propios miembros del equipo cuánto ha sido de productiva la sesión. De este modo pueden aflorar síntomas de algo que no esta funcionando bien y podría mejorarse hablándolo en la siguiente retrospectiva. Inspeccionar y adaptar, la base de Scrum.