El refinamiento es una herramienta clave de los equipos Scrum. Nos ayuda a dejar ready los elementos futuros que desarrollaremos en los próximos Sprints. Sin embargo, Scrum apenas dispone de reglas referentes al refinamiento. El motivo es simple, Scrum apenas invierte esfuerzo en la toma de requisitos y el Product Management deja mucha libertad ya que se centra en la entrega. En este artículo, trabajaremos técnicas para encajar el refinamiento en nuestros Sprints.
Refinamiento o Product Management
Durante años creí que el refinamiento se entendía como el trabajo que el Product Owner realiza con el cliente, customers, users o cualquier otro stakeholder clave. Sin embargo, el refinamiento se utiliza con la finalidad de aportar luz al Product Owner sobre el trabajo de los próximos Sprints.
Todo trabajo que realiza el Product Owner con personas ajenas al Scrum Team se considera Product Management. En estas labores, Scrum no prescribe absolutamente nada. Obviamente, cada vez que tenemos conversaciones con los clientes o potenciales usuarios modificamos el Product Backlog.
El refinamiento se refiere a la unión del Product Owner con los Developers del Scrum Team para trabajar los items del Product Backlog y poder adelantarnos a futuros impedimentos: dependencias, dudas no resueltas, elementos demasiado grandes…
¿Quiénes asisten al refinamiento?
Uno de los debates más interesantes a tener con los equipos es quiénes deben refinar. Por un lado, podemos asistir todo el equipo, pero no debe convertirse en un adelanto de la Sprint Planning. El motivo es sencillo, dejamos de trabajar para enfocarnos en el trabajo futuro, para después volver a nuestras tareas. Si os ocurre esto, es mejor hacer una Sprint Planning más larga que desfocalizar al equipo.
Hay equipos que disponen de figuras como el technical lead o similar. Recordemos que Scrum propone que todos tengamos la misma responsabilidad de developer, lo que supone que todos deberíamos actuar de manera similar. Ahora bien, si de manera natural, el equipo decide que una persona les represente es viable.
La única regla que Scrum determina es que solo se use el 10 por ciento del tiempo total de los Developers para la labor de refinar. Estudiemos tácticas.
Refinamiento con Fecha Fija
Una de las técnicas más simples es fijar fechas fijas para el refinamiento. Por ejemplo, si nuestra Sprint Planning empieza en lunes y nuestro cambio de Sprint en viernes, pues usar los miércoles por la tarde para refinar. De esta manera, todos tenemos ese tiempo reservado para esta labor.
Con esta técnica, perdemos flexibilidad pero ganamos en constancia y disciplina. Por tanto, es ideal para equipos que arrancan y que quieren generar la costumbre en Scrum. El problema es que hay semanas en las que tendremos fiestas o vacaciones y podría afectarnos.
Refinamiento con fecha variable por Sprint
Siguiendo el hilo anterior, una buena técnica es debatir durante la Sprint Planning el momento de refinar. Así, en cada Sprint determinaremos los tiempos de refinamiento.
Esto nos permite adecuarlo a cada Sprint aunque perderemos en constancia, lo que puede ser un problema. Podría ocurrir que, durante la Sprint Planning, no dispongamos de huecos por estar ocupados en otras reuniones, al haber tardado tanto en determinar el hueco.
Refinamiento por partes
Otra opción que he podido experimentar consiste en hacer el refinamiento por partes. En un equipo con el que trabajé hace años, hicimos el siguiente acuerdo: la primera semana de Sprint, la Product Owner escribía los requisitos que ella consideraba/necesitaba. Después, el miembro más experto del equipo se sentaba con ella a analizarlo. Si había dudas, se consultaba al resto del equipo.
Esta manera de refinar permitía que no interrumpiéramos a todo el equipo para refinar, solo para casos difíciles. A la Product Owner le costaba diferenciarlo, por eso le ayudaba el analista del equipo. De esta manera, conseguimos mayor fluidez y optimizamos el tiempo de refinamiento.
Refinamiento bajo demanda
Hace meses participé varias semanas como Product Owner supliendo a un compañero. Inicialmente, teníamos programados varios huecos para refinar. Sin embargo, a veces no había suficiente trabajo preparado, por lo que teníamos conversaciones que eran poco fructíferas.
Se nos ocurrió cambiar el método. La UX que lideraba el avance se reunía conmigo regularmente. Cuando íbamos teniendo suficiente trabajo para refinar, avisábamos al equipo en el Daily Scrum. Y entonces, agendábamos una reunión para refinar. De esta manera, aprovechábamos el tiempo, solo nos veíamos cuando era necesario.
Refinamiento por item
Esta es mi técnica favorita y la aprendí de un equipo de Thoughtworks con el que tuve el placer de coincidir. Ellos se organizaban en la Sprint Planning a nivel de tareas del Sprint y de refinamiento. Hacían un reparto de los items a refinar entre parejas. Cada pareja se hacía responsable de una cantidad de items que debían refinar con el Product Owner durante el Sprint.
De esta manera, se optimizaba mucho el trabajo, siempre había developers que conocían el item, pero no todos conocían todos. Además, la pareja que había refinado era candidata a hacer el desarrollo (aunque no era obligatorio que así fuera). De esta manera, ganábamos en fluidez y velocidad en la entrega.
Y tú, ¿cuándo haces el refinamiento?
