Backlog Refinement

La sesión de refinamiento de backlog o backlog grooming es una reunión o evento que se lleva a cabo durante el sprint y que tienen como objetivo poner el foco en trabajar en las historias de usuario próximas a ser construidas por el equipo de desarrollo.

Esta técnica de refinamiento trabaja sobre el artefacto de Scrum Product Backlog, por lo que te dejo acceso al link si quieres profundizar tus conocimientos acerca del mismo.

Esta reunión no es un evento oficial incluido en la Scrum Guide pero tiene muchas similitudes con el evento Sprint Planning debido a que su valor reside en ir preparando y alistando aquellas historias de usuario para luego ser incorporadas en el evento Sprint Planning y así ser incluías (o no) en el futuro Sprint.

Para que la reunión sea eficiente, es importante tener claros los roles involucrados y las actividades correspondientes a cada uno.

Esencialmente, este evento consta de 3 pasos:

1) Presentación de Historias de Usuario

• En este paso el Product Owner explica EL QUÉ.
  Qué es lo que hay que hacer, para qué y por qué.
  Tiene que ser muy claro en la comunicación y dar a conocer todos los detalles necesarios desde la perspectiva y visión de negocio.
  
  

  
  

• El Product Owner comienza la reunión comunicando de forma clara el objetivo y las características principales de cada historia de usuario, así como también el valor y el impacto esperado de cada una para la organización, el mercado y el negocio.

  
  

• Es clave evidenciar la importancia y la relación de construir esta historia en este momento (sprint) y la contribución de la misma al Objetivo del Producto (Product Goal).
  
  

2) Desglose de Historias de Usuario

• Una vez que se hayan presentado las historias de usuario (EL QUÉ), es momento de pasar al COMO, y en este paso es momento de la intervención del rol Equipo de Desarrollo que es quien tiene la responsabilidad.

  
  

• El Product Owner puede estar presente o no en esta instancia, pero si tiene que estar disponible en caso de que existan dudas y que se requiera de alguna explicación extra o de desambiguar en algún aspecto.

  
  

• En este instancia, el Equipo de Desarrollo ¡única y exclusivamente! se encarga de descomponer en tareas técnicas las historias de usuario. Es importante remarcar esto, debido a que el equipo que construye el producto, es decir el que tiene el know how y sabe como hacerlo, es el encargado de desglosar en tareas el requerimiento de negocio solicitado.

• Para cada historia de usuario presentada, el equipo va conversando y colaborando acerca de cuales son las tareas necesarias a incluir para la construcción de esa historia de usuario.
  El objetivo de esto, es disminuir la incertidumbre y proveer de la certeza necesaria acerca que es necesario hacer para construir cada historia de usuario además de que esta certeza es fundamental para el próximo paso: La estimación.

  
  
  

3) Estimación de Historias de Usuario

• Ya habiendo comprendido el alcance de la historia de usuario, su valor e impacto esperado de negocio y habiendo desglosado esta en tareas específicas para su comprensión y para aumentar el grado de certeza para su realización, ahora el siguiente paso es estimar.

  
  

• Es muy importante destacar que las estimaciones de historias de usuario son responsabilidad exclusiva del equipo de desarrollo. Ellos son los que tienen el conocimiento técnico para construirlas, por lo tanto son los que pueden realizar estimaciones acordes en base a su experiencia profesional como de estimaciones previas.
  
  
  
  
  
  
  
  
  
  
  

  
  

• Existen varias técnicas de estimación como ser T-Shirt Size, Planning Poker o Relative Estimation entre otras. Si es de tu interés conocer mas sobre el tema, te dejo un enlace relacionado para profundizar estos coneptos: Estimaciones.

  
  
  Algunas recomendaciones que suelo hacer sobre las sesiones de refinamiento del product backlog, tienen que ver con el momento de llevarlas a cabo en el sprint en curso, la frecuencia y la duración del evento.

  
  
  Mi sugerencia es que se trate de reuniones livianas, es decir con poca carga de trabajo de una o dos historias de usuario máximo por sesión, que se realicen al menos 1 vez por semana y no mas de 1.5 horas por sesión.
  
  De esta forma, el equipo lo toma como algo llevadero y si se implementa de forma descontracturada puede ser un espacio divertido y de cohesión para el Scrum Team además de que tener el hábito de hacer Backlog Refiement, contribuye a tener sesiones de Sprint Planning mucho mas cortas y eficientes.
  
  ¿Como sabemos si la historia de usuario ya está refinada completamente?
  
  Para esto, es recomendable combinar esta práctica con otra que llamada Definition of Ready o Definición de Listo en donde se establecen los criterios necesarios de equipo para considerar a una historia de usuario como lista para ser incorporada en un Sprint.

Conclusiones

• Respetar los roles y sus responsabilidades en la creación y ejecución del evento.

• Hacer sesiones cortas y en lo posible descontracturadas para hacerlas atractivas.

• Mientras mas hagamos Backlog Grooming, la Sprint Planning serán mucho mas sencillas.

• El QUE, es responsabilidad del Product Owner.

• El COMO, es responsabilidad del Equipo de Desarrollo.

• El desglose de tareas y las estimaciones, son responsabilidades del equipo de desarrollo.
  .