El Juego de Estimación del Equipo es una técnica que facilita la Planificación de Sprint en Scrum. ¿En qué se diferencia del Planning Poker? ¿Por qué algunos Equipos de Desarrollo lo consideran una herramienta más efectiva y otros no? Encontrarás todo lo que necesitas saber al respecto en el siguiente artículo.
Juego de Estimación del Equipo – tabla de contenido:
- Introducción
- Reglas del Juego de Estimación del Equipo
- Juego de Estimación del Equipo versus Planning Poker
- Resumen
Introducción
El Juego de Estimación del Equipo también se llama Estimación en Carriles de Nado. Este último término se originó como una observación espontánea de un juego de cartas, ya que la disposición de las cartas se asemejaba a los carriles de nado de una piscina.
El Juego de Estimación del Equipo está ganando popularidad constantemente, ya que permite a los Equipos de Desarrollo crear estimaciones aproximadamente 3 veces más rápido que usando Planning Poker.
Escribimos sobre esta técnica en el artículo anterior. Hoy, centrémonos en el Juego de Estimación del Equipo.
Reglas del Juego de Estimación del Equipo
Indicaciones del Juego de Estimación del Equipo:
- un mazo de cartas de Historias de Usuario – preparado por separado para cada juego
- un mazo de cartas de Puntos de Historia – para uso repetido
Primero, apila las cartas de Historias de Usuario en el orden correspondiente a las entradas en el Product Backlog. Para asegurar que las más urgentes sean estimadas primero.
Las cartas de puntuación suelen contener valores correspondientes a la secuencia de Fibonacci. Esta es una secuencia de los siguientes números: 0, 1, 3, 5, 8, 13, 20, 40 y 100. También puedes etiquetarlas con potencias sucesivas del número 2, es decir, 2, 4, 8, 16, 32, y así sucesivamente.
Las fases del juego de estimación del equipo:
- Introducción. Para jugar el Juego de Estimación del Equipo, los miembros del Equipo Scrum se sientan alrededor de una mesa. El Product Owner comienza sacando la primera carta del mazo de Historias de Usuario y compartiendo su contenido con todos. Luego, las cartas permanecen sobre la mesa. Luego, el Product Owner explica al resto del Equipo Scrum que a partir de ahora, los jugadores evaluarán las Historias de Usuario como fáciles o difíciles de implementar colocándolas de acuerdo a la izquierda y a la derecha. Si alguna tiene algún grado de dificultad, el jugador las apilará, una encima de la otra sobre la mesa. Ahora, la persona sentada a su lado en el sentido de las agujas del reloj hace el siguiente movimiento.
- Un jugador saca una carta del mazo de Historias de Usuario. Después de compartir su contenido con todos, explica su esencia al Product Owner. La persona que sostiene la carta luego la coloca sobre la mesa y selecciona un lugar basado en su opinión sobre la dificultad de esta Historia de Usuario. Luego, el jugador explica la razón detrás de la elección a todos y los otros jugadores son libres de hacer preguntas sobre el razonamiento. No pueden cuestionar la decisión en sí, sino los argumentos que justifican la decisión.
- Ahora, los jugadores toman un turno y tienen dos opciones para elegir:
- Repetir el paso 2, o
- Mover una de las cartas sobre la mesa a su posición más apropiada
- La etapa final de colocar las cartas de Historias de Usuario ocurre una vez, o muchas veces, dependiendo de la práctica del Equipo Scrum. Durante esta ronda, cada jugador tiene otra oportunidad de mover una de las cartas sobre la mesa a un lugar más apropiado.
- Una vez que los jugadores asignan todas las cartas de Historias de Usuario a sus ubicaciones que representan niveles de dificultad, el Equipo de Desarrollo pasa a igualar el valor asignando las cartas del montón de Puntos de Historia. La primera carta de Historia de Usuario a la izquierda recibe la carta de Puntos de Historia con el menor número de puntos por parte del Product Owner. La regla para colocar las cartas subsiguientes es la misma que para los puntos 3 y 4. Esto completa la estimación.
Si eligen la segunda opción, también deben justificar qué les hizo cambiar de opinión. Los jugadores se turnan repitiendo el paso 3 hasta que todas las cartas del mazo de Historias de Usuario sean distribuidas y estimadas.
Juego de Estimación del Equipo versus Planning Poker
El Juego de Estimación del Equipo se considera una herramienta de estimación más efectiva que el Planning Poker. Debido a las siguientes diferencias entre estas dos técnicas:
- Regla de la carta-mesa. El Juego de Estimación del Equipo utiliza la conocida “regla de la carta-mesa” de los juegos de cartas populares. Esto significa que una vez que has colocado una carta, no puedes devolverla. Debido a que la Historia de Usuario es estimada por una persona a la vez, la fluctuación entre estimaciones y el número de veces que se cambian las posiciones es significativamente menor, en comparación con el Planning Poker.
- Un cálculo lo suficientemente preciso. En el Planning Poker, se debe alcanzar un consenso completo para cada Historia de Usuario. En el Juego de Estimación del Equipo, sin embargo, solo una persona decide. Incluso si su estimación es incorrecta, otro Desarrollador probablemente la colocará en un valor que coincida más precisamente. De esta manera se garantiza alcanzar estimaciones suficientemente precisas y rápidas.
- Agotar el tema de discusión. Discutir elecciones a menudo se vuelve excesivamente largo al jugar Planning Poker. Su tiempo se reduce considerablemente durante un Juego de Estimación del Equipo porque se centran en una sola decisión de uno de los Desarrolladores en lugar de la naturaleza de cada Historia de Usuario.
Un posible inconveniente del Juego de Estimación del Equipo es una sensación de injusticia. Si el Equipo de Desarrollo es más grande que el número de Historias de Usuario programadas en un Sprint dado, algunos Desarrolladores pueden sentirse excluidos.
Juego de Estimación del Equipo – resumen
El Juego de Estimación del Equipo tiene la opinión de ser la técnica de estimación más efectiva para la mayoría de los Equipos Scrum. Sin embargo, es importante recordar que es solo una herramienta para estimar la dificultad y el esfuerzo de las Historias de Usuario. Y como cualquier herramienta, debemos ajustarla para que se adapte a las necesidades y capacidades de los miembros del Equipo.
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Como Gerente de Proyectos, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo presión de tiempo la convierten en la mejor persona para hacer realidad proyectos complicados.
Scrum Guide:
- Glosario de términos básicos, roles y nociones
- ¿Qué es Scrum?
- Valores de Scrum
- ¿Cómo implementar Scrum en tu empresa?
- Equipo Scrum - ¿qué es y cómo funciona?
- ¿Quién es un Product Owner?
- Los errores más comunes del Product Owner
- ¿Quién es el Scrum Master?
- Los errores más comunes del Scrum Master
- ¿Qué estadísticas y métricas debería seguir el Scrum Master?
- Equipo de Desarrollo en Scrum
- Los errores más comunes de los desarrolladores
- Artefactos de Scrum
- Escalando Scrum
- Sprint Backlog
- ¿Qué es el Product Backlog?
- ¿Qué son las Historias de Usuario?
- Creando la mejor Historia de Usuario con INVEST
- Los errores más comunes en las User Stories
- Criterios de Aceptación de la Historia de Usuario
- Estimación y Puntos de Historia en Scrum
- Planificación Poker
- Juego de Estimación del Equipo
- Definiendo Incremento
- Eventos de Scrum
- ¿Qué es un gráfico de quema?
- Ventajas y desventajas del gráfico de burndown
- Tableros Kanban en Scrum y Scrumban
- Velocidad en Scrum - Velocidad del Equipo de Desarrollo
- Scrum diario
- Planificación del Sprint
- Revisión del Sprint
- ¿Qué es una Retrospectiva de Sprint?
- Errores comunes durante una Retrospectiva de Sprint
- Cuidado del Product Backlog
- ¿Cómo crear e interpretar un gráfico de burndown?