RespuestasAgiles: ¿Cómo realizar el Refinamiento en Scrum?

¿Cuándo podríamos estimar una historia de usuario con mejor certeza? La matriz de Stacey, una técnica a usar en el Refinamiento

Hola a todos

La matriz desarrollada por Ralph Stacey, conocida como la Matriz de Stacey, permite entender cuando de acuerdo con los ejes de Requerimientos y Tecnología, podemos tener una aproximación de gestión simple, complicada, compleja;

Matriz de Stacey. Tomado de (1)

 

y dados estos escenarios, se ha usado en los últimos años, para justificar en que escenarios trabajar con métodos tradicionales y cuando con enfoques ágiles (existen cientos de artículos al respecto).

Matriz de Stacey. Tomado de (2)

Usando este mismo enfoque, podríamos identificar en un taller de Inception o de Refinamiento, cuando una historia de usuario o una épica incluye mucha o poca incertidumbre para ser estimada y, por ende, desarrollada, tanto desde el punto de vista de requerimientos, como de tecnología, proporcionándonos estimaciones indirectas sobre tiempos y esfuerzos requeridos (toda estimación incluye una probabilidad y una incertidumbre asociada).

La zona donde cualquier equipo de desarrollo, ágil o no, estima con confianza, es aquella donde hay alta certeza en los requerimientos y alto certeza en la tecnología y forma de construirlo. Los Product Owners deben procurar que la mayoría de las historias de usuario y épicas que llevan a un equipo se encuentran en esta zona. Ahora, si existe incertidumbre, podríamos hacer uso de técnicas de partición de historias de usuario (3) o de spikes para realizar investigaciones de aquellos elementos que no se encuentran claros al momento de desarrollar.

Los equipos ágiles deben preferir historias en esta zona de confianza, y estos elementos podría hacer parte de una Definición de Ready o Preparado adecuada, para que las historias puedan ser incluidas en el planning. Los siguientes criterios que garantizan esta zona de estimación con certeza: 

• Las historias cumplen cumplen INVEST y las 3C
• Existe un entendimiento consistente de parte del product owner y del equipo acerca de la historia de usuario.
• Las historias cuentan con claros criterios de aceptación 
• Se han resuelto las dependencias técnicas y funcionales
• Las ambigüedades se han resuelto
• El tiempo para construir-probar-desplegar la historia de usuario se encuentra en horizontes de tiempo menor o igual a 4 días-persona (esto es una heurística que he observado en los equipos ágiles, en este número de dias las estimaciones son más certeras y confiables. Habrá que hacer un estudio riguroso para confirmar mi experiencia e hipótesis).

Para cerrar, los invito a que usen esta matriz para realizar refinamiento de historias de usuario con sus equipos, asegúrense que existe certidumbre en la tecnologia y acuerdo en los requerimientos, de esta forma fluirán mejor sus sesiones de planning y no se enfrascarán en discusiones innecesarias.

Saludos ágiles,

Jorge Abad

Referencias

1. Entendiendo la complejidad: La matriz de Stacey - https://academy.jeronimopalacios.com/courses/145560/lectures/5315213
2. https://www.researchgate.net/figure/Stacey-Matrix-Stacey-1996-adapted-to-software-development_fig3_336899045
3. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario

La Guía de Scrum 2017 - En Mapa Mental

Hola a todos

La Guía de Scrum, la oficial, la publicada en https://scrumguides.org/, y en su versión en español para suramérica en 2017 https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf  traducida por mi estimado amigo Lucho Salazar, es un trabajo de sus creadores Jeff Sutherland y Ken Schawber de más de 20 años sobre ella.

Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero muy resumida.

Muchas veces al hacer una lectura de la misma, no somos conscientes de la cantidad de información allí depositada, y como nos pasa a muchos, cada vez que vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento para entender lo allí descrito, (me decía mi amiga Paola Becerra,  el ojo ve lo que es capaz de interpretar).

Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en formato de mapa mental.

Mapa Mental - Capítulos

Mapa Mental - Capítulos y Subcapítulos

El ejercicio no fue muy estricto desde las recomendaciones para crear mapas mentales, pero si con miras a ubicar fácilmente conocimiento clave.

Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una idea de lo extenso del mapa)

De igual forma, he marcado en color verde y con (*) el texto relevante o las perlas ocultas a mis ojos del pasado.

Descárgalo y Úsalo

A continuación, pongo a su disposición varios formatos de descarga y visualización

• Descargar PDF - aquí  (es el más sugerido debido al tamaño, debes descargar y abrir desde un navegador web, como: Chrome, Edge, o Firefox, etc)
• Word - aquí
• PNG Aqui
• SVG - aquí

Espero que esta decodificación les sea tan útil como lo fue para mí, en este entendimiento y reestudio de la guía.

Disfruten las perlas (las que estan con asterisco (*) y en verde)

Saludos ágiles

Jorge Abad

[Agenda Scrum] Pasos para Realizar el Refinamiento

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Refinamiento(2), actividad que se sugiere realizar en la mitad del sprint:

1. El Scrum Master (SM) comparte el propósito, dinámica y timebox de la sesión
2. El Product Owner (PO) comparte el objetivo del siguiente o subsiguientes sprints
3. El PO comparte cada una de las historias de usuario con el Team
4. El Team hace preguntas buscando que las historias estén en Ready (3) para el planning correspondiente ( requisitos claros, tecnología y herramientas claras, dependencias externas resueltas)
5. El PO responde las preguntas
6. En caso de que el PO no pueda responder una pregunta, toma nota para resolverla para el planning en que está programada
7. El Team puede realizar sugerencias sobre estrategias de construcción del proximo Sprint Backlog, el PO decide si las acoge o no.
8. Cuando se terminen las historias planeadas a compartir se termina la reunión.
9. Actualizar las herramientas de gestión.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo
2. Esta reunión no tiene como objetivo escribir las historias de usuario, aunque algunas pueden ser escritas, divididas o fusionadas.
3. Recomiendo este post - La Definición de “Ready” es tan importante como la Definición de “Done”

Gráficas para Facilitación de Retrospectivas y Reuniones

Hola a todos

Hace un tiempo luego del uso de Retromat (http://plans-for-retrospectives.com/index_es.html) (1) me he hecho muy amigo de la visualización de información en forma gráfica durante las retrospectivas (u otras sesiones de trabajo), considero que es una forma fácil y poderosa de compartir información, pensamientos, mejoras, relaciones, etc.. A continuación les comparto un grupo de gráficas que he usado y otras que me he encontrado y que a modo personal considero que transmiten mucha información, encuentren y fabriquen las de ustedes.

Bienvenido el feedback y la mejora de este listado.


Saludos ágiles
Jorge Abad

Posibles gráficas a usar durante el inception y el refinamiento

Gráfica para clasificar el valor y riesgo de las historias de usuario o ítemes de backlog

Gráfica para clasificar y priorizar historias o ítemes de backlog según impacto y esfuerzo

Posibles gráficas a usar durante una retrospectiva

Gráficas para "armar el escenario" y calificar el sprint al inicio de la retrospectiva

Gráficas para "armar el escenario" y calificar el sprint al inicio de la retrospectiva

Gráfica para "indagar" durante la retrospectiva y evaluar la calidad de los canales de comunicación durante el sprint

Gráfica para "decidir que hacer" de forma que permita clasificar y priorizar las mejoras según impacto y esfuerzo

Gráficas para el "cierre" y permiten calificar la eficacia de la retrospectiva

Notas, aclaraciones, comentarios y referencias

1. Retromat es una aplicación o repositorio de actividades de retrospectivas que te permite generar una amplia variedad de combinaciones para tus sesiones de mejora con tu equipo

Scrum: La Reunión de REFINAMIENTO, clave para reducir Riesgos y reducir tiempo del Sprint Planning

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

Dice la guia [1]:

"El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y
orden a los elementos de la Lista de Producto. Se trata de un proceso continuo, en el cual el
Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos
de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan 
sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente 
consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos
de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a
criterio suyo."

Bajo este escenario la duración de la reunión de refinamiento debería ser:

	Duración máxima de la reunión en horas
Tamaño del Sprint	1 Semana	2 Semanas	3 Semanas	4 Semanas
Refinamiento	1	2	3	4

Si lo miramos bien toma un tiempo considerable del sprint (aunque he experimentado en sprints de 2 que semanas 4 horas son suficientes),  tal vez se haga en una sola sesión o en varias según el caso, pero una de las ideas claves de scrum es:

"tengamos las reuniones suficientes de manera que no sea necesario hacer más reuniones, y podamos enfocarnos en lo que nos gusta, la construcción del producto."

.

Lo cierto es que esta actividad tiene grandes beneficios tanto para el sprint que viene, como para la construcción del producto.

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 o tres próximos y discutir aspectos sobre ellos. Una de las agendas que he empleado en los refinamientos es la siguiente:

1. Lectura y estimación de las historias de usuario que posiblemente entran en el PRÓXIMO SPRINT. Se leen las historias de usuario con sus criterios de aceptación, se realiza la conversación, entendimiento y ajuste sobre las mismas.
2. Lectura de historias de usuario (no al detalle, solo el título de las mismas) que entrarán en los próximos  2 ó 3 sprints
3. En equipo se identifican los insumos requeridos para estas historias tanto desde el punto de vista de conocimiento como de entes externos al equipo (otras áreas, otros proveedores, etc)
4. En equipo se identifican los riesgos que pueden hacer que esas historias no se completen y se identifican actividades a realizar para mitigarlos.

De este manera:

• El Scrum Master y el Product Owner (y en ocasiones el Team Develper) comienzan a trabajar conjuntamente en la resolución previa de:
• riesgos
• insumos 
• e impedimentos
• El equipo conoce que viene para el próximo sprint
• El planning es una reunión mas liviana donde se presentan los aspectos modificados o afinados de las historias de usuario y algún cambio en la priorización.
• Todo el Equipo Scrum (Product Owner, Scrum Master, Team Developer) van observando como se va construyendo la visión del producto y se pueden alinear desviaciones.

Saludos ágiles

Jorge Abad.

Referencias

[1]Scrum Guides - https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100

Tiempos máximos de las reuniones de Scrum según el tamaño del Sprint

Hola a todos

A continuación relaciono el tamaño máximo de las reuniones de Scrum, según el tamaño del sprint. Estos tiempos fueron extraídos de la guía de Scrum [1]:

Tamaño del Sprint	1 Semana	2 Semanas	3 Semanas	4 Semanas
	Duración máxima de la reunión en horas
Sprint Planning	2	4	6	8
Sprint Review	1	2	3	4
Sprint Retrospective	0,75	1,5	2,25	3
Daily (15 minutos)	0,25	0,25	0,25	0,25
Refinamiento (tiempo máximo)	4	8	12	16

La idea es que estos  tiempos se respeten, logrando el TIMEBOX o tiempo asignado para el objetivo defnido.

Es importante resaltar los siguientes aspectos:

• El Scrum Master como dueño del proceso, es responsable de que estos tiempos no se superen.
• Los primeros 2 o 3 sprints es muy probable que no se cumplan con los TIMEBOX, pero se debe trabajar en equipo y en la retrospectiva buscando la causa y las acciones a realizar para que esto no se repita. 
• Los únicos TIMEBOX que desde el inicio se deben respetar son:
• Daily = 15 minutos
• Duración del Sprint = la definida (no se sugiere estar cambiando la duración de sprints, se debe buscar trabajar a un ritmo regular y constante)

Saludos ágiles
Jorge Abad.

Referencias

[1]Scrum Guides - https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100