EL TABLERO DE REFINAMIENTO
RefinementBoard
Ese momento: Antes de facilitar, una ceremonia de refinamiento
La idea: Enseñar al equipo Scrum, un retrato simbólico que refleje el resultado de su trabajo al cierre de la ceremonia, buscando platearles preguntas como ¿Qué historias están suficientemente clarificadas, para decir que están listas para la ceremonia de planificación?, ¿Qué historias aun no tienen refinamiento suficiente?, ¿Donde hace falta refinar?.
Emplear ayudas visuales, son un medio que genera valor importante en la facilitación de ceremonias Scrum. En este caso les comparto lo que diseñé para la sesión de refinamiento, como instrumento para el equipo, donde al expresar "visualmente" la atención del Backlog, les dará claridad de haber seguido los pasos correctos y les muestre el panorama de las historias de usuario y la preparación requerida para afrontar la ceremonia de planificación.
Mi esencia: Me llevo a diseñar un tablero (similar al juego de Ludo o Parques) con tres objetivos específicos. El Primero, mostrar como la conversación entre el equipo SCRUM (Equipo de trabajo y Product Owner), debe permitir que cada historia de usuario antes ordenada por prioridad en el Backlog, siga un recorrido específico que le prepare para hacer parte de la agenda en la ceremonia de planificación. Un Segundo, servir como instrumento de conexión entre el equipo de trabajo, el cómo y el propósito de realizar el refinamiento de las historias de usuario. Por ultimo (al menos visto desde mi perspectiva) el tercer objetivo, mostrar una fotografía que ejerza como disparador de acciones a tomar, mostrando el efecto que puede causar que, luego de un refinamiento las historias aún estén en camino y no sobre la posición central, "lista para planificación".
¿Cómo se usa?
El tablero no es una herramienta que refina una historia de usuario, tampoco implica dejar que, cada historia de usuario haga un recorrido a la suerte y que el azar lo resuelva.
El tablero, representa el estado o el viaje de las historias de usuario durante una ceremonia de refinamiento y sobre el cual prima como regla de oro, la previa priorización de cada historia de usuario, permitiendo hacer libres representaciones de la administración del backlog, bajo un esquema libre a definir y del cual se deriven hasta 4 posibles puntos de salida, según se desee explorar el recorrido de las historias durante el refinamiento, las variantes propuestas para su clasificación son:
- Por prioridad de las historias: Express, Fecha fija, Estándar, Intangible.
- Hasta para cuatro iteraciones
- Hasta para cuatro características
- Hasta para cuatro sistema
Las historias de usuario, simbólicamente representan las fichas que recorren el tablero (para mayor claridad definir a criterio un código o nombre por cada historia y distinguir por color como es sugerido en el tablero) desde un Backlog de punto de partida, para producto de la conversación entre el equipo SCRUM, buscar lleguen la mayor cantidad al punto central.
El recorrido y desplazamiento, es basado en un juicio razonado que hace el equipo SCRUM, premisa de entendimiento y acuerdo por cada asunto (refiriéndome a los pasos que marcan el recorrido del tablero). Además, conduce a tomar decisiones de abortar la discusión de una historia cuando no se resuelven impedimentos o se está dedicando más tiempo del disponible sin conseguir resolver un asunto.
El equipo SCRUM, desempeña el rol de único participante, con lo cual pretendo decir que no se busca necesariamente dividirles para atender cada grupo de historias (lo cual pudiera no ser lo más adecuado al aislar el conocimiento y entendimiento, pero si el contexto es de historias a resolver por personas específicas vale la pena explorar) que tratan en una única conversación.
La dinámica, una a una son tomadas las historias de usuario para ser refinadas (llevarles del punto de partida al centro del tablero), que como antes mencione, es producto de una conversación que entre más efectiva se resuelva, más pronto llegará al punto central objetivo. Si uno de los pasos del recorrido tiene un asunto que no puede ser resuelto, se puede tomar nota (parking Lot) y pasar a la siguiente historia en prioridad, con esto se busca hacer de la ceremonia algo dinámico donde no se pierda tiempo en asuntos que en ese TimeBox no se podrán resolver o terminan afectando la agenda y revisión restante del Backlog.
El cierre, corresponde a la finalización del TimeBox de la ceremonia, sobre el tablero, cada historia marcará el viaje que fue posible realizar y que tanto se logró refinar cada historia.
Resultado final, sobre el cual, el equipo SCRUM evaluará decisiones y buscará resolver acciones pendientes sobre el estado de refinamiento del Backlog, aquí un argumento "visual" para resolver la pregunta ¿Qué tan preparados estamos para la ceremonia de planificación?. La dinámica deberá ser continuada en una posterior sesión, una vez resueltos los asuntos pendientes o en medida se van incorporando nuevas historias.
Para descargar el tablero, acceder al siguiente enlace
Si tienes problemas para la descarga, al final dejo mis datos de contacto. Muchas gracias por su interés es esta publicación, quedo muy al pendiente de sus comentarios, sus experiencias y logros en la práctica.
Cordialmente,
Sergio Pardo - Agile Coach
https://www.linkedin.com/in/sergiopardo/
Twitter: @Sergio_E_Pardo
Correo: sepg.sergio.pardo@gmail.com
