Guía Scrum | 25. Juego de estimación de equipos

Team Estimation Game es una técnica que facilita la planificación de Sprint en Scrum. ¿En qué se diferencia de Planning Poker? ¿Por qué algunos equipos de desarrollo consideran que es una herramienta más eficaz y otros no? Encontrarás todo lo que necesitas saber al respecto en el siguiente artículo.

Juego de Estimación en Equipo – índice:

1. Introducción
2. Reglas del juego de estimación de equipos
3. Juego de estimación de equipos versus Póquer de planificación
4. Resumen

Introducción

El juego de estimación de equipos también se llama estimación de Swimlanes. El último término se originó como la observación espontánea de un juego de cartas, ya que la exhibición de cartas se asemejaba a los carriles de natación de una piscina de agua.

Escribimos sobre esta técnica en el artículo anterior. Hoy, concentrémonos en el Juego de Estimación de Equipos.

Reglas del juego de estimación de equipos

Indicaciones del juego de estimación en equipo:

• una baraja de cartas de User Stories , preparadas por separado para cada juego
• una baraja de cartas Story Point – para uso repetido

Primero, apile las tarjetas de Historias de usuarios en el orden correspondiente a las entradas en el Product Backlog. Para garantizar que los más urgentes se calculen primero.

Las tarjetas 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 etiquetarlos con potencias sucesivas del número 2, es decir, 2, 4, 8, 16, 32, y así sucesivamente.

Las fases del juego Estimación por equipos:

1. Introducción. Para jugar el Juego de Estimación en Equipo, los miembros del Equipo Scrum se sientan alrededor de una mesa. El propietario del producto comienza sacando la primera carta del mazo de historias de usuario y compartiendo su contenido con todos. Entonces, las cartas se quedan sobre la mesa. Luego, el propietario del producto 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 a la izquierda y a la derecha según corresponda. Si alguno tiene algún grado de dificultad, el jugador se apilará uno encima del otro en la mesa. Ahora, la persona sentada a su lado en el sentido de las agujas del reloj hace el siguiente movimiento.
2. Un jugador roba 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 tiene la tarjeta la coloca sobre la mesa y selecciona un asiento según su opinión sobre la dificultad de esta Historia de usuario. Luego, el jugador explica la lógica detrás de la elección a todos y el otro jugador es libre de hacer preguntas sobre el razonamiento. No pueden cuestionar la decisión en sí sino los argumentos que la justifican.
3. Ahora, los jugadores toman un turno y tienen dos opciones para elegir:
• Repita el paso 2, o
• Mueve una de las cartas de la mesa a su posición más adecuada

Si opta por la segunda opción, también deberá justificar qué le hizo cambiar de opinión. Los jugadores se turnan para repetir el paso 3 hasta que se hayan distribuido y estimado todas las cartas del mazo de historias de usuario.

4. La etapa final de colocar las tarjetas de historias de usuario ocurre una o varias veces, según la práctica del Equipo Scrum. Durante esta ronda, cada jugador tiene otra oportunidad de mover una de las cartas de la mesa a un lugar más apropiado.
5. Una vez que los jugadores asignan todas las tarjetas de Historias de usuario a sus ubicaciones que representan niveles de dificultad, el Equipo de desarrollo avanza para igualar el valor asignando las tarjetas de la pila de Puntos de historia. La primera tarjeta de historia de usuario a la izquierda obtiene la tarjeta de punto de historia con el número más bajo de puntos por parte del propietario del producto. La regla para colocar las cartas posteriores es la misma que para los puntos 3 y 4. Esto completa la estimación.

Juego de estimación de equipos versus Póquer de planificación

El Team Estimation Game se considera una herramienta de estimación más eficaz que Planning Poker. Debido a las siguientes diferencias entre estas dos técnicas:

• Mesa de cartas. El juego Team Estimation utiliza la conocida "regla de la tabla de cartas" de los juegos de cartas populares. Esto significa que una vez que haya colocado una tarjeta, no podrá retirarla. Debido a que la historia del usuario es estimada por una persona a la vez, la fluctuación entre las estimaciones y la cantidad de veces que cambia de posición es significativamente menor, en comparación con Planning Poker.
• Un cálculo suficientemente preciso. En Planning Poker, se debe llegar a un consenso completo para cada historia de usuario. En Team Estimation Game, sin embargo, solo una persona decide. Incluso si su estimación es incorrecta, es probable que otro desarrollador lo coloque en igualar su valor con mayor precisión. De esta manera se garantiza llegar a estimaciones lo suficientemente precisas y rápidas.
• Agotar el tema de discusión. Discutir las opciones suele ser demasiado largo cuando se juega a Planning Poker. Su tiempo se reduce considerablemente durante un Juego de Estimación en Equipo porque se enfocan en una sola decisión de uno de los Desarrolladores en lugar de la naturaleza de cada Historia de Usuario.

Un inconveniente potencial del Juego de Estimación por Equipos es una sensación de injusticia. Si el Equipo de desarrollo es más grande que la cantidad de Historias de usuario programadas en un Sprint determinado, algunos Desarrolladores pueden sentirse excluidos.

Juego de Estimación de Equipos – resumen

Team Estimation Game tiene una opinión sobre la técnica de estimación más efectiva para la mayoría de los equipos Scrum. Sin embargo, es importante recordar que solo es una herramienta para estimar la dificultad y el esfuerzo de las Historias de usuario. Y como cualquier herramienta, debemos ajustarla para que coincida con las necesidades y capacidades de los miembros del Equipo.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, 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 la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos