Gestión de Historias de Usuario - Planning Poker
Minuto 00:00 - 00:45 | Apertura
Es crucial que un equipo tenga una visión clara del esfuerzo que se requerirá para construir los elementos del Product Backlog. Para ello, debemos estimar, considerando variables como el esfuerzo, la complejidad y la incertidumbre de cada elemento. Hoy, vamos a explorar una técnica colaborativa y muy efectiva para lograr esto: el Planning Poker.
<Ideas clave/> Minuto 00:45 - 02:30 | Estimación Relativa y el Planning Poker
Una de las tecnicas usadas en Scrum para estimar es la estimación relativa. La estimación relativa es la práctica de estimar el tamaño de las historias de usuario o elementos del Product Backlog comparando unas con otras, en lugar de usar unidades de tiempo fijas (como horas o días). Esto nos ayuda a enfocarnos en la complejidad, la incertidumbre y el tamaño del trabajo.
Veamos un ejemplo para entender este concepto:
Supongamos que nuestro reto es determinar cuánto pesa cada uno de los animales, teniendo en cuenta, por ejemplo, la dimensión de cada animal. Para ello, inicialmente vamos a definir un pivote:
Un pivote es un ítem del backlog en el que todos los miembros del equipo se ponen de acuerdo para definir un peso, con este pivote definido se compara con las otras actividades y se determina si es menor, mayor o igual que el pivote. Se recomienda usar la escala de la serie fibonacci: los valores 1, 2, 3, 5, 8, 13 y 20
Para nuestro ejemplo, vamos a definir que el pivote será el Zorro, a quien asignaremos un valor de 3 (este será nuestro pivote). Siendo así, ¿cuánto podría pesar el Gorila, en comparación con el Zorro?. Una de las respuestas podría ser 8 o 13. ¿Y el peso del elefante en comparación con el Zorro?, La respuesta podría ser 20, pues la dimensión del Zorro vs el Elefante es mucho mayor.
Para que esta estimación sea divertida y colaborativa, usamos una técnica llamada Planning Poker. El Planning Poker es una técnica de estimación de consenso, basada en el juego, que utiliza la secuencia de Fibonacci (1, 2, 3, 5, 8, 13...). Cada número en esta secuencia representa un nivel de complejidad o tamaño.
¿Cómo funciona?
- El Product Owner presenta una historia de usuario o un elemento del Product Backlog, y los Desarrolladores tienen la oportunidad de hacer preguntas para comprenderlo a fondo.
- Cada Desarrollador elige una carta en secreto que representa su estimación de esfuerzo para ese elemento.
- Todos los Desarrolladores revelan sus cartas al mismo tiempo.
- Si las estimaciones son muy diferentes, los Desarrolladores con las cartas más altas y más bajas explican su razonamiento. Esto fomenta el debate y la identificación de diferentes perspectivas o supuestos ocultos.
- El equipo discute y puede repetir el proceso hasta que se llegue a un consenso o a un rango de estimaciones aceptable.
Esta técnica no solo ayuda a asignar un tamaño a los elementos, sino que es una excelente manera de fomentar la comunicación, la colaboración y una comprensión homogénea del trabajo.
<Práctica/> Minuto 02:30 - 04:30 | Llevando a cabo un Planning Poker
(Apoyo audiovisual: un video corto o animación de un equipo real llevando a cabo un Planning Poker).
Narrador: Imaginemos a nuestro equipo de la aplicación de aprendizaje de idiomas. El Product Owner presenta una nueva historia de usuario: "Como usuario, quiero poder grabar mi pronunciación y compararla con la de un hablante nativo, para mejorar mi acento".
(Video/Animación: El Product Owner lee la historia. Los desarrolladores hacen preguntas. Luego, cada uno toma una carta y la pone boca abajo. Al contar hasta tres, todos voltean sus cartas).
Desarrollador 1: (Muestra un 8) "Hay que integrar la grabación, comparar audios, y eso es complejo."
Desarrollador 2: (Muestra un 3) "Podríamos usar una API existente para la comparación de audio. No es tan difícil."
Desarrollador 3: (Muestra un 13) "Pero hay que manejar permisos de micrófono en múltiples plataformas, y la integración de audio siempre es delicada."
Narrador: El equipo discute. El desarrollador con el '3' se da cuenta de la complejidad de los permisos que no había considerado. El desarrollador con el '13' explica los desafíos de la integración de audio. Después de la discusión, el equipo decide votar de nuevo, y esta vez, todos revelan un '8' o un '13', acercándose más a un consenso y a una mejor comprensión de la historia.
<Cierre/> Minuto 04:30 - 06:00 | Conclusiones y reflexiones
El Planning Poker es de gran valor para eliminar ambigüedades en un equipo y para generar un conocimiento homogéneo de la complejidad a la que se enfrentan. Ahora, te pregunto: ¿En qué otras situaciones crees que esta práctica de estimación podría ser útil en tu trabajo o en tu organización? ¿Quizás para estimar proyectos personales o tareas del hogar? Compartenos tus comentarios en el chat
Nos vemos en la siguiente clase, donde continuaremos explorando los artefactos de Scrum