Muchas veces, la reunión de Refinement es incomprendida por los equipos Scrum. Esto puede ser debido al hecho que falta un poco de contexto a la hora de entender cómo funcionan las reuniones y, especialmente, cómo funciona el Sprint en un proyecto en Scrum.
Para explicarlo de una forma sencilla: La reunión de Refinement sirve para todo aquello que es necesario para el éxito del proyecto; y que no está cubierto por el resto de reuniones estándares de Scrum (Sprint Planning, Sprint Review, Sprint Retrospective i Daily).
Entonces podemos (o deberíamos) preguntarnos: ¿Qué es necesario hacer en el proyecto que no pueda tratarse en una planning, review o retro?
A continuación, tratamos de explicar las más críticas.
En ocasiones, en el curso de un sprint, aparece cualquier cosa no prevista. Una barrera tecnológica, un problema organizativo en el equipo, un problema de comunicación con alguno de los interesados o, muy a menudo, dudas sobre aquello que es creía entendido.
Hay una máxima en la gestión de proyectos, por todos conocida: Los problemas deben tratarse en cuanto aparecen. No es buena práctica esperar a una Review para tratar un problema. De hecho, podría considerarse una falta de respeto hacia al Product Owner (recordemos los valores ágiles: compromiso, enfoque, receptividad ante los cambios, respeto y coraje). La Review es el lugar para mostrar el incremento y verificar el valor que produce en la organización. No es el lugar para resolver problemas que están afectando el Sprint.
Cuándo hay un problema, las partes afectadas y las partes que pueden proporcionar alguna solución o mitigación, se reúnen de la forma más ágil y rápida posible. Esta reunión es un Refinement dentro del marco de trabajo Scrum.
Un aspecto que en ocasiones resulta un poco complicado de entender por parte del equipo, es que el Sprint no sirve únicamente para construir aquello comprometido en un Sprint Planning. Este tiempo de Sprint también debe servir para algunas acciones necesarias que afectan la calidad y la estabilidad del Product Backlog:
Estas acciones se llevan a cabo de forma natural en el mismo tiempo y espacio (el Sprint) en que estamos construyendo el incremento comprometido. En lo referente al primer punto, acostumbran a ser reuniones planificadas en agenda. El equipo técnico se reúne de forma periódica para entender completamente historias de usuario que deberá construir en un futuro inminente, con la ayuda del Product Owner y de los Stakeholders.
Este “entender” comporta, necesariamente, bajar el detalle de la necesidad planteada por el negocio, y complementarla con toda la información que sea necesaria para que el equipo pueda llegar a un conocimiento completo de esta. Esto comporta, forzosamente, la definición de los criterios de aceptación. Estos criterios son responsabilidad del negocio, y tratan de explicar qué premisas, condiciones y comprobaciones se llevarán a cabo para poder dar por válida una historia de usuario concreta o un incremento en su conjunto.
En lo referente al segundo punto, recoger nuevas necesidades o tratar cambios que se producen en el negocio, son un ejemplo de adaptación continua con agilidad. El cambio es bienvenido en el proyecto, y se transforma en más trabajo en el backlog. El cambio no puede ser un elemento distorsionador del trabajo de los técnicos y, por tanto, el cambio no puede afectar a los objetivos a corto en que el equipo se ha comprometido, ni afectar a su auto-organización.
Todo esto tiene impactos sobre el Product Backlog. Y es responsabilidad de todo el mundo, incluidos los miembros del equipo técnico, mantener actualizados los ítems del product backlog con toda esta información nueva o cambios que se negocian en estas reuniones de Refinement.
Una historia de usuario cualquiera no puede construirse si, entre otras informaciones, no tenemos un conocimiento sobre el esfuerzo que comporta hacerla realidad. Para esto es imprescindible que el equipo técnico los trabajo en lo que se conoce cómo Refinemientos de estimación. Cuándo el equipo tiene un conocimiento completo de la necesidad a construir, producto de reuniones de Refinement par avanzar trabajo que hemos visto en el punto anterior, está listo para hacer una valoración o estimación del esfuerzo que comporta hacerla realidad.
Usualmente, el equipo se reúne de forma periódica par hacer estimaciones de diversas historias de usuario. Existen diversas dinámicas para celebrar esta reunión de la forma más eficiente posible, y las explicamos en otro artículo. Aquí solo haremos énfasis sobre la necesidad de hacer este ejercicio de forma constante durante los Sprints, para que, al llegar al Sprint siguiente, el equipo disponga de toda la información necesaria para poder construir las historias más interesantes en cada momento.
A diferencia del resto de reuniones del marco de trabajo Scrum, no existe un TimeBox claramente establecido para las reuniones de Refinement. Al ser reuniones que se llevan a cabo de forma variable durante los Sprints, no hay una recomendación estándar sobre cuántas se deberían celebrar. Únicamente tenemos las recomendaciones siguientes:
| Todo completamente detallado y estimado | INVEST | Ítems basados en componentes |
|---|---|---|
| Todos los ítems del product backlog están detallados y estimados. El equipo debe trabajar únicamente sobre aquello que se llevará a cabo en plazos razonables | Los ítems del product backlog deben ser INVEST (Independent, Negotiable, Valuable, Estimable, Sized appropriately & Testeable) | Un ítem del product backlog debe describir una necesidad “end-to-end”. Y no una solución asignable a una vertical tecnológica |
| Sin criterios de aceptación | No se hacen refinements | Dedicación del Product Owner |
|---|---|---|
| Un ítem del product backlog no sólo debe describir una necesidad. También debe dar orientaciones sobre como ésta va a ser validada | La comprensión del product backlog se obtiene sólo gracias a los refinements. El equipo dialoga con el PO sobre lo ítems mas prioritários | Un product backlog con baja dedicación del PO conlleva una mala comprensión de la necesidad, errores de estimación y baja calidad en los resultados |
Descarga el esquema para imprimir aquí
