Llevar adelante un excelente refinamiento en Scrum es parte de la clave para que la empresa pueda ser exitosa. Sin ello, la compañía derrochará un montón de dinero y hará que sus productos lleguen más tarde, perderá segmento de mercado, alargará los tiempos de desarrollo e impactará sobre la moral de sus equipos.
El refinamiento es una sesión clave en Scrum donde se clarifican ideas para que los miembros de la compañia o integrantes del equipo puedan tener una base consistente sobre un problema que está experimentado un cliente o una hipótesis que se tiene y se desea resolver o comprobar.
Existen 3 tipos de refinamiento:
- Aquellos que se realizan durante la incepción de un proyecto o en etapas tempranas para refinar los conceptos iniciales del producto
- Los que se realizan dentro del Sprint cada intervalos regulares o lo que llamo refinamientos periódicos del problema (qué)
- Los refinamientos esporádicos o refinamientos de la solución (cómo)
En éste artículo te explicaré los 2 últimos puntos, dejando la primera para algún momento, ya que pertenece más al comienzo de una iniciativa ágil en sí.
Existen varios escenarios que me he cruzado en distintas empresas, la primera es que no se realicen refinamientos, se deje para el último día o se haga dentro del Sprint Planning (Planeamiento del Sprint) como parte del mismo.
En general, ello es la consecuencia de que los equipos aduzcan no tener tiempo para poder hacer la sesión, se les quite su foco sobre las tareas diarias o no existan historias o problemas concretos a resolver hasta el día anterior a un Sprint Planning.
La situación anterior se da en empresas con Product Owners (Propietarios de Producto) con menos experiencia, organizaciones con poco conocimiento de agilidad donde se tienen mundos mixtos (un área Scrum y el resto de la empresa tradicional) o donde los equipos tienen presión interna o externa para llegar a una fecha de entrega.
En muchas ocasiones incluso los mismos miembros del equipo ejercen entre sí una presión social exacerbada para cumplir con la fecha estipulada, mientras que en otros casos es el propio Product Owner o la organización de donde provienen las señales. Lo importante aquí es identificar donde se origina cada una de ellas, ya que la aproximación será diferente en cada caso.
Refinamientos periódicos del problema
La sesión se realiza cada un intervalo regular de tiempo donde se analiza el problema/hipótesis presentada desde el punto de vista del QUÉ. ¿Qué es lo que el cliente quiere, qué problema se está tratando de resolver y cuando se considera resuelto?
Ten en cuenta que no hablamos durante ésta sesión sobre CÓMO se concretará a nivel técnico, ya que ello se dejará para el último minuto responsable, que es normalmente en la sesión Sprint Planning.
Una pregunta recurrente es cada cuanto hay que efectuar los refinamientos y cuál es su estructura.
Te pondré aquí varios ejemplos basados en mi experiencia:
- Si Product Owner, equipo o empresa es nueva con agilidad y Scrum, 3 sesiones de 45 minutos máximo por semana de Sprint es una buena opción.
- Si es un Product Owner y equipo experimentado que ha trabajado en conjunto con Scrum y sobre el mismo producto por un período de tiempo razonable y cuenta con excelencia técnica (integración continua, estándares de código, TDD, ATTD, excelente comunicación intra y inter equipos, etc.), se puede pensar en 2 sesiones a la semana de 30 minutos.
Es importante que tengas en cuenta que si bien los refinamientos son el momento donde se junta todo el equipo para centrarse en el qué de un problema, Product Owner deberá seguir refinando la pila (Backlog) de historias de Usuario durante el resto de su día y tiempo. De hecho, y para que sea eficiente, Product Owner requiere una dedicación mínima de 80% al equipo y producto. Al fin y al cabo, el éxito dependerá de la dedicación y calidad de los refinamientos.
Esto último es normalmente difícil de negociar en organizaciones donde la mayor parte de la gestión se hace de forma tradicional o las personas están más preocupadas en subir la escalera corporativa que servir al equipo/producto.
Digamos que tenemos ya reservada la sala (¡Y sí! la mayor parte de empresas tienen problemas de espacio y disponibilidad de salas al comenzar con Scrum) y todo el equipo Scrum está dispuesto a reunirse esos días.
¿Qué debería pasar en la primera sesión?
Mi primera recomendación es que el equipo defina anteriormente sus reglas de etiqueta, esto es, que cosas serán aceptadas o no durante la sesión y ponerlas visible durante la reunión (ej. No teléfonos celulares o computadores a no ser emergencia familiar, todo el equipo junto, estar en hora, etc.)
Es recomendable también trabajar en un borrador de la definición de listo (Definition of Ready).Este es el acuerdo entre todas las partes a seguir a la hora de que Product Owner y equipo de desarrolladores puedan considerar una historia de usuario lista para ser movida de refinamiento a candidata de ser comenzada en un Sprint.
Nadie quiere ni es saludable que aparezca sin previo aviso debajo de una manga una historia de usuario un minuto antes de comenzar un Sprint Planning. Ello bajaría la moral del equipo, destruiría la confianza y traería un número indeseable de efectos negativos en el corto y mediano plazo.
Aquí tienes un ejemplo de varios elementos de una definición de listo (DOR), pero pueden haber muchos otros:
- La historia de usuario está bien definida
- El criterio de aceptación se entiende y se comparte por todos
- Las dependencias de alto nivel se conocen así como los riesgos
- El equipo tiene una idea a alto nivel sobre la experiencia de usuario actual y deseable
- La historia tiene un tamaño asignado
- El equipo se siente confortable que realmente lo que se está tratando de resolver es un problema para el cliente
- Se han pasado por al menos 2 refinamientos de la historia antes de un Sprint Planning
- (Opcional) Que la historia tenga un valor asignado de puntos de negocio (Cuánto vale la historia para la empresa y porqué)
Acuérdate de mantenerlo sencillo de no más de 5 o 6 puntos y empuja para que se mejore y simpliifique cada intervalos regulares de tiempo.
¿Qué debería pasar en el resto de sesiones?
En las sesiones posteriores Product Owner deberá presentar las historias de usuarios o sus ideas sobre qué es lo que se quiere solucionar, que le duele al usuario y como se lo haría más feliz. En mi experiencia, es siempre una buena aproximación que éste lleve todas las historias de usuario en fichas de papel y las pegue en la pared de forma visible. El hecho de utilizar una herramienta computacional (ej. Jira, Trello, version One, etc.) ocasiona un detenimiento para las interacciones sociales entre los miembros del equipo y otras personas invitadas a la sesión. Una tarjeta se puede rayar, mover, subrayar, romper, dibujar, y tiene un tamaño máximo donde escribir lo cual fuerza a mantener la “esencia” o simplicidad de lo que se desea resolver.
El Scrum Master es esencial aquí ya que deberá trabajar algunas horas o días antes para facilitar la sesión y que Product Owner tenga todo lo necesario en la sala así como las instrucciones sobre que se espera que brinde a la reunión.
Es importante que se ponga un tiempo fijo por historia (ej. 10 o 15 minutos) y el equipo se mueva a la próxima al finalizar el lapso estipulado. Ello asegura una cadencia y que no se entre en un agujero negro donde el equipo se centre durante toda la sesión en discutir una única historia.
Aquí nuevamente Scrum Master debería cronometrar el tiempo y observar si todos los integrantes participan por igual. Es muy común que alguno de los miembros haya sido Líder técnico antes de comenzar con Scrum y participe e influencie mucho más. En estos casos, recomiendo emplear el mapa de interacciones para balancear los diálogos y decisiones.
Recapitulando, no se habla de cosas técnicas, se focaliza en el problema a solucionar o hipótesis y la travesía de ese usuario concreto para conocer si se está presentando el problema/hipótesis adecuada y se está plasmando ella en una historia de usuario.
Se deberá analizar en a intervalos regulares si la historia cumple con la definición de listo (DOR) y de no ser así, ver que pasos serían necesarios para acercarse a ella.
Durante el proceso es recomendable también asignar un tamaño a la historia, para ello, con equipos nuevos es saludable el emplear la triangulación.
Este sistema es sencillo y se basa en elegir una de historia de referencia que sea clara para todo el equipo y no demasiado grande o pequeña y asignar números (puntos de historia) o tamaños de ropa (S, M, L, XS) basado en cuan más grande son las otras en comparación con esta.
En equipos con más experiencia quizás el dar tamaño no sea necesario, pero recuerda que es buena idea el comunicar al resto de la empresa que algo que se hará es muy grande o más bien pequeño.
Es también una buena opción que cada historia contenga puntos de negocio (Business Value Points), esto es, un valor relativo de cuánto se piensa que vale para la compañía el no tener dicha historia disponible y que pasaria si se tuviese.
TAMAÑO: 8 Valor de negocio: 400
Cómo cliente de AutoParking deseo poder pagar por mi estacionamiento sin necesidad de tener que bajarme del coche
Criterio de aceptación:
– Que cubra al menos el 90% de los usuarios
– Que no lleve más de 1 minuto
– Que la persona pueda conocer el tiempo restante
Recuerda que aquí no se habla de cómo se hará técnicamente, sino que el foco estará exclusivamente en tratar de determinar la validez del problema o de la hipótesis, lo que se desea resolver, sus dependencias de alto nivel y riesgos.
Las dependencias se pueden documentar en cada tarjeta o incluso si ocurre entre dos o más de ellas, emplear un hilo para amarrarlas, flechas o cualquier otra técnica que deje clara la misma.
Algunos ejemplos de dependencias de alto nivel:
- Personas a quien contactar para verificar la historia
- Conocimiento de negocio a obtener
- Información a verificar
- Otras historias
- Conocimiento de la aplicación
- Trabajo de otros equipos que éste depende
Es normal que los equipos de software comiencen a tratar de resolver el problema (Cómo), por ejemplo, ver si se utilizará JavaScript, un servidor, el teléfono móvil, etc. pero es importante que comprendan que ello se abordará más adelante.
Scrum Master deberá estar atento para mantener el foco de la sesión para así asegurar que la solución técnica pueda estar abierta hasta el último momento responsable (cuando se comienza el Sprint). De lo contrario se estará congelando algo que podría ser obsoleto.
Abordar la solución técnica aquí trae muy posiblemente la pérdida de foco y el apadrinamiento de la solución, lo que conlleva a una menor flexibilidad. Esto se da cuando un sub-grupo brinda una solución y se siente orgulloso de haberla propuesto, lo que hace que sea más reacio a cambiarla posteriormente.
Muchas empresas a su vez crean el término Historia Técnica para poder hablar de trabajos técnicos/no funcionales durante los refinamientos. Éste término no existe, se debe llamar tarea técnica y no es tampoco aquí el momento de hacerlo. El objetivo de un refinamiento es alinear al equipo con el problema/hipótesis y conocer si éste es en realidad la raíz del asunto, ver las dependencias y establecer el clima para que se enfoque hacia la solución y conversaciones adecuadas.
Durante la sesión se van leyendo una a una las historias de usuario y se espera que el equipo sea honesto con respecto a si entiende la misma, está bien redactada, se siente confortable con el alcance, etc. Incluso se podrían invitar especialistas de negocio para realizarle preguntas o personas que brinden información relevante.
Si el equipo es nuevo, un coach o una persona con concimiento de redacción de historias de usuario podría ser necesaria en éste punto.
Existe también otro tipo de elemento que son comunes durante un refinamiento y son los llamados Spike (o picos). Ellos son tareas de investigación donde el resultado será información o conocimiento para poder tomar una o más decisiones, pero no se deben confundir con implementaciones técnicas que se consoliden como parte del producto.
“Conocer el número de personas que sería afectado si X no está”
“Saber si es posible usar JQuery con la aplicación de parking”
Ellas son también parte del refinamiento y es recomendable que cuenten con un criterio de aceptación. Recuerda que durante el Sprint, los Spike deberán tener un tiempo máximo de 4 a 6 horas.
Una vez finalizada la sesión, Producto Owner tomará notas y se volverá a repetir el proceso en la siguiente sesión. Se puede también obtener retro-alimentación de los asistentes en intervalor regulares para la mejora continua.
Recuerda que todo el equipo es el dueño de la sesión de refinamiento y no algunos roles en particular.
Refinamientos esporádicos de la solución
Muchos equipos se preguntan cuando se hablará de la parte técnica, y ello conlleva a que exista mucho nerviosismo en ocasiones dentro del equipo de desarrollo. En principio, durante el planeamiento del Sprint o Sprint Planning, pero ello no es del todo cierto ni recomendado.
Es aquí donde los refinamientos esporádicos de la solución ocurren; ellos son esenciales y se debe tener un espacio y hábito para que se materialice.
La idea es que los miembros del equipo de forma casual/informal comiencen a conversar en su día a día sobre posibles soluciones, problemas e inconvenientes. Este es lo que llamo pláticas cruciales, lo que dista mucho de ser un planeamiento estructurado.
Pedro: Juan, ¿viste la historia X? Creo que JavaScript es una buena alternativa porque si lo usamos en la aplicación móvil de parking no habrían todos estos problemas…
Juan: Es cierto, pero no lo hemos utilizado nunca. Ahora que me acuerdo, Alfonso lo usó antes y tiene mucha pero mucha experiencia, hoy a la tarde podemos hablar con él, y si es así el tamaño de la historia bajaría y sería más fácil de hacerlo.
Pedro: ¡Excelenta! Hagámoslo y luego hablamos con el equipo.
Este tipo de refinamientos del “como” deberían existir día a día, lo que se traduce en conversaciones que hacen posible sintonizar y conectar a los miembros con una idea o hipótesis y sus posibles soluciones, así como también restricciones de conocimiento o tecnologías u otros riesgos. Esto también se puede traducir en charlas con otras áreas de la empresa, áreas de arquitectura, etc.
El equipo puede posteriormente brindar sus resultados durante el refinamiento programado siempre y cuando se traslade a posibles riesgos en vez de las soluciones técnicas en sí.
Cuando no se da lugar para éste tipo de refinamientos esporádicos, el equipo intentará hablar de la parte técnica durante el refinamiento programado o bien en la sesión de Sprint Planning, lo que hará que se convierta en interminable.
Finalmente, si más de un equipo trabaja sobre el mismo producto (Escalabilidad), alguno de los refinamientos programados deberían ser en conjunto o al menos contar con miembros de ambos equipos. Recuerda que ésto último no debería practicarse con equipos nuevos; empieza pequeño y luego crece.
Y recuerda, si necesitas conocer más sobre como potenciar equipos Scrum y Ágil dentro de tu empresa, o sobre mi último Libro sobre Agilidad empresarial (Leading Exponential Change), visita mi sitio Web.
Gracias por escucharme y suerte con tu próximo refinamiento,
Erich.
