Tips de refinamiento

Esta reunión, no oficial de scrum, tiene como objetivo, presentar los próximos ítemes de backlog al equipo que van a entrar tanto para el siguiente sprint como para los 2 ó 3 próximos y discutir aspectos sobre ellos. 

El refinamiento aunque no es una de las reuniones oficiales de Scrum, si se dice que el 10% del sprint debería dedicarse a esta actividad:

"El refinamiento (refinement) del product backlog es el acto de añadir detalle, estimaciones y

orden a los elementos esta lista. Se trata de un proceso continuo, en el cual el product owner y el equipo revisan los detalles de las  historias del product backlog. El equipo decide cómo y cuándo se hace el refinamiento, el que usualmente no consume más del 10% de la capacidad del equipo, sin embargo, las historias pueden ser actualizadas en cualquier momento por el product owner."

A continuación, para preparación del evento tener en cuenta:

• Enviar cita a los involucrados con el objetivo de la reunión, timebox, lugar, fecha, hora,
• Asegurarse de tener los materiales (post-it, sharpies, marcador de pizarra),
• Preparar la sala 5 a 10 minutos antes (sillas, espacio, proyector),
• Definición de la cantidad esperada de historias a refinar en la sesión agendada,
• Definición tentativa de las historias de usuario que se tomarán en el siguiente sprint,
• Nombrar las historias tentativas que vendrán en el siguiente y sub-siguiente sprint

Durante al evento:

• Mantener foco, incorporar acuerdos de trabajo para ello (no smartphone, no labtop, breaks, evitar que personas acaparen la reunión),
• Acotar tiempo de revisión por historia, asignar un tiempo fijo  (p.e.  para refinamiento de una hora, si se requiere revisar 3 historias, se asignan 20 minutos por historia)
• Chequear las 3cs (Card, Conversation, Confirmation), la historia debe estar escrita (papel ó digital), lo escrito debe generar conversación coherente, los criterios de aceptación deben estar definidos,
• Chequear criterio INVEST, que los miembros del equipo mencionen en que parte de la historia cumple con los criterios, por ejemplo, ver que es negociable (a través de los CA) o como la podríamos testear,
• Identificar los riesgos e impedimentos, indagar como afrontar la historia, dependencias, que nos impide realizar la historia (impedimento)  y que lo podría ser en el futuro (riesgo),
• Dividir la historia de usuario, desafiar a miembros del equipo a dividir la historia, podría ser a través de criterios de aceptación, o alguna técnica de slicing,
• Cuestionar el valor de la historia, rotar personas en el equipo, que sin argumentos personales cuestionen la utilidad (usuario y solución) de la historia, esto puede implicar un cambio de prioridad,
• Separar refinamiento técnico de lo de negocio, considerar refinamiento para afrontar deuda técnica,  UX,  servicios, entre otros separada del aspecto de negocio,
• Medir alineamiento, conforme avanza el evento, preguntar a los participantes acerca de lo que quiere decir alguna parte en particular de una historia, esto para identificar si todos están entendiendo lo mismo,
• Pre-estimación relativa de la historia, utilizar alguna técnica para la estimación relativa de la historia.

Al terminar, nos llevamos el entendimiento de las historias a tomar en los próximos sprints.

Swing-lane sizing

Esta técnica se utiliza para medir el tamaño de un backlog y recalibrarlo, se aplica cuando ya hay un conocimiento compartido de las historias de usuario, pero aún no se han estimado.

Materiales

• Pizarra,
• Marcadores,
• Títulos de historias de usuario en post-it,
• Serie de Fibonacci escrita en post-it (1, 2, 3 5, 8, 13, 20, 40, 100),
• Equipo de desarrollo en un refinamiento o planning.

Instrucciones

Dibujar a lo ancho de la pizarra una línea horizontal (carril) con un signo menos (-) a la izquierda y un signo más (+) a la derecha,

Primera ronda (en silencio)

• Los desarrolladores se ubican en fila y el facilitador tiene las historias en su mano como un mazo,
• El primer desarrollador toma una historia de usuario y la pone al centro del carril,

• En turnos, los siguientes desarrolladores toman las siguientes historias, las leen y las más pequeñas a su criterio la ubican a la izquierda del carril y las más complejas a la derecha en orden de magnitud, hasta finalizar con el mazo.

Segunda ronda (en silencio)

• Con el escenario resultante de la primera ronda, todos se deben cuestionar si algunas de las historias deben cambiar de posición, 
• Los desarrolladores se ubican en fila, cada uno solo puede tomar una historia y cambiarla de posición, en su turno debe explicar el por qué del cambio,
• Si en su turno, el desarrollador opina que en el orden de las historias que ve, no hay nada que cambiar dice en voz alta "paso",
• A medida que va variando el escenario, si hay desarrolladores que piensan que hay más cambios que aplicar se suman a la fila nuevamente,
• La ronda finaliza cuando todos los desarrolladores piensan que ya no hay más movimientos que hacer y dicen "paso".

Tercera ronda (con fibonacci en post-it)

• Los desarrolladores se ubican en fila nuevamente y ahora el facilitador tiene en su mano los post-it de la serie de fibonacci como mazo del número más pequeño al más grande,
• El primer integrante toma el primer post-it y lo ubica sobre la historia más pequeña y así sucesivamente los siguientes compañeros, posicionando el post-it donde se genera el quiebre.

Con esta dinámica la estimación de las historias puede ser mucho más ágil que aplicando planning poker durante la lectura de historias en el refinamiento y/o reunión de planificación.

T-shirt sizing

Esta técnica se utiliza para clarificar ítems de trabajo entre sí, según orden de magnitud, generalmente se usa en estimaciones relativas de historias de usuario.

Se suele usar 5 medidas que representan el esfuerzo:

• XS, extra small,
• S, small,
• M, medium,
• L, large
• XL, extra large

Materiales

• Persona que sabe el detalle de la historia de usuario,
• Equipo de desarrollo para consensuar la estimación,
• 1 baraja de t-shirt por desarrollador

En las barajas de t-shirt, aparte de las cartas con los tamaños, se pueden agregar cartas con,

• signo de interrogación, para indicar que hay demasiada incertidumbre para estimar la historia, 
• signo de infinito, para indicar que el tamaño de la historia se escapa a los limites de estimación,
• una taza de café, para tomarse un descanso en el proceso de estimación.

Instrucciones

• El equipo define las características definidas para las medidas correspondientes a cada ítem,
• El responsable de la funcionalidad lee una historia de usuario,
• Los desarrolladores votan simultáneamente con la carta que piensan, corresponde al tamaño,
• Las personas mas alejadas del consenso dan sus razones, y se trata de llegar a consenso,
• Se anota la estimación y se continúa con la siguiente historia de usuario.

Planning poker

Creada por James Grenning esta técnica fue ideada para la participación y colaboración en la estimación relativa de historias de usuario, su base es el consenso.

Materiales

• Persona que conoce el detalle de la funcionalidad,
• Equipo de desarrollo para consensuar la estimacion,
• 1 baraja de planning poker por desarrollador.

En las barajas de planning poker, aparte de la serie de fibonacci, se pueden agregar cartas con,

• signo de interrogación, para indicar que hay demasiada incertidumbre para estimar la historia, 
• signo de infinito, para indicar que el tamaño de la historia se escapa a los limites de estimación,
• una taza de café, para tomarse un descanso.

Instrucciones

• El facilitador toma una historia de usuario, y el responsable de la funcionalidad la explica y resuelve las dudas,
• Se da el turno a la estimación, cada desarrollador de su baraja toma sin mostrar la carta correspondiente a la estimación relativa de acuerdo a su criterio y experiencia,
• Una vez que todos tienen su carta, la revelan simultáneamente,
• Las personas más alejadas del consenso (puntuación más baja y  más alta), explican el por qué de su valoración,
• Se puede hacer una nueva tirada si no hay consenso,
• Se anota la estimación y continúa con la siguiente historia de usuario.

Good, better, best

Esta técnica permite dividir una historia estableciendo el mínimo producto viable.

Materiales

• Pizarra,
• Título de historias escritas en post-it,
• Marcadores.

Instrucciones

• Tomar una historia del backlog, pegando su post-it respectivo en la pizarra,
• Leer la historia en voz alta,
• Preguntar ¿Qué funciones básicas (GOOD ENOUGH) se deben considerar para que esta historia funcione?
• Anotar las funciones básicas en post-it, una por cada post-it, y pegarlas en una primera línea al lado de la historia,
• Preguntar ¿Qué otras funciones básicas podrían mejorar (BETTER) esta historia?
• Anotar las funciones en post-it, y pegarlas como segunda línea al lado de la historia,
• Finalmente, preguntar ¿Qué funcionalidades la harían realmente fabulosas? (BEST),
• Anotar las funciones en post-it, y pegarlas como tercera línea al lado de la historia.

De esta forma tienes separado que es lo básico para que las historias se desarrollen y qué es a lo que se puede bajar prioridad.