Votación con puntos (dot voting): priorización, no estimación
La votación con puntos no es en absoluto una técnica de estimación; es una herramienta de priorización que los equipos usan cuando en realidad quieren estimar, y confundir ambas cosas produce un backlog que está ordenado pero no dimensionado. Esta página cubre cómo funciona realmente la votación con puntos, por qué pertenece a una conversación distinta de "qué tan grande es esto", y dónde se ubica junto a la estimación real. Para la familia completa de técnicas, consulta la guía completa de estimación ágil.
Cómo funciona la votación con puntos
Cada participante recibe un número fijo de "puntos" (puntos adhesivos físicos en persona, o clics en una herramienta digital) para distribuir entre una lista de opciones como prefiera. Todos los puntos de un participante en un solo favorito, o repartidos entre varios: ambas opciones son válidas. Una vez que todos han votado, las opciones con más puntos son la prioridad del grupo, punto final. No hay discusión incorporada en el mecanismo de la forma en que la hay en Scrum Poker; la votación con puntos es rápida específicamente porque se salta la conversación por elemento.
Una configuración típica: cinco opciones, cada participante recibe tres puntos. Alguien podría poner los tres en una opción que le importa mucho; otra persona reparte un punto entre tres opciones distintas que estaría igualmente contenta de ver priorizadas.
Qué pregunta responde realmente
La votación con puntos responde "qué importa más a este grupo, ahora mismo", no "cuánto esfuerzo tomará esto". Son preguntas genuinamente distintas, y todo el modo de falla de usar mal la votación con puntos consiste en tratar una señal de popularidad como una señal de dimensionamiento. Una funcionalidad puede ganar todos los puntos de la sala y resultar ser el elemento más costoso de la lista; la votación con puntos no te ha dicho nada sobre eso.
Este es el error más común que cometen los equipos con la técnica: recurrir a la votación con puntos porque un backlog "necesita ser estimado", cuando lo que realmente se necesita es una decisión sobre qué construir primero. Las dos preguntas merecen dos ejercicios separados, idealmente en ese orden: priorizar primero, y luego estimar solo los elementos que sobrevivieron a la priorización.
Dónde se ajusta genuinamente la votación con puntos
Decidir qué construir entre varias opciones viables. Un equipo con diez funcionalidades candidatas para el próximo trimestre y capacidad para tres usa la votación con puntos para sacar a la luz la preferencia genuina del grupo rápidamente, sin un largo debate sobre cada una individualmente.
Combinarla con el mapeo de historias. Primero se mapea el recorrido del usuario para ver qué historias son centrales para la experiencia frente a las opcionales, luego se vota con puntos dentro de un nivel de prioridad para desempatar entre opciones de importancia aproximadamente igual. La estimación con Scrum Poker ocurre después, solo sobre las historias que sobrevivieron a la priorización; la votación con puntos reduce la lista, no dimensiona lo que queda. Más sobre el lado del mapeo: mapas de historias para priorización.
Selección de temas de retrospectiva. Fuera por completo del trabajo de backlog, la votación con puntos es una forma rápida de que un equipo elija cuál de varios temas de discusión de la retro merece el tiempo limitado en la sala; un caso de uso genuinamente distinto, pero el mismo mecanismo subyacente.
Un ejemplo trabajado
Un equipo tiene doce ideas candidatas para una revisión de roadmap trimestral y treinta minutos para reducirlas. Cada uno de ocho participantes recibe cuatro puntos. Los puntos caen en la pared junto a notas adhesivas para cada idea; las personas votan simultáneamente para evitar el mismo problema de anclaje que enfrenta la estimación numérica (un par de puntos tempranos y visibles pueden influir en dónde caen los puntos posteriores, así que la colocación simultánea importa aquí también).
A los quince minutos, tres ideas han absorbido la mayoría de los treinta y dos puntos, cuatro tienen una dispersión escasa, y cinco no tienen ninguno. El equipo se compromete con las tres principales para un análisis más profundo y deja de lado el resto: una decisión de priorización genuina, rápida e impulsada por el grupo. Notablemente, nadie tiene todavía idea de qué tan grandes son en realidad esas tres ideas; esa es la siguiente conversación, ejecutada por separado, probablemente con t-shirt sizing dado lo temprano que siguen estando las ideas.
Votación con puntos vs. técnicas de estimación
| Votación con puntos | Scrum Poker / t-shirt sizing / etc. | |
|---|---|---|
| Pregunta respondida | ¿Qué importa más? | ¿Qué tan grande es esto? |
| Discusión incorporada | No; rápida por diseño | Sí; la discusión sobre el desacuerdo es el valor |
| Resultado | Una lista ordenada o filtrada | Un tamaño o estimación en puntos |
| Alimenta la velocidad | No | Sí (con la técnica adecuada) |
El error común, y la solución
Usar la votación con puntos donde el equipo realmente necesitaba una estimación produce un backlog que está confiadamente ordenado y completamente sin dimensionar, lo cual se manifiesta como una sorpresa un sprint o dos después, cuando "lo que todos querían más" resulta ser también el elemento más grande que nadie dimensionó. La solución es procedimental, no técnica: trata la priorización y la estimación como dos ejercicios separados con dos preguntas separadas, ejecuta primero la votación con puntos (o cualquier método de priorización), y estima solo los elementos que la sobreviven.
Estima lo que priorizó la votación con puntos
Una vez que la votación con puntos ha reducido la lista, dimensiona lo que queda con una técnica de estimación real. Crea una sala gratis y ejecuta Scrum Poker sobre las historias que pasaron el corte: votos privados, una revelación, la conversación que la votación con puntos deliberadamente se salta.