La estimación en puntos de historia compara el esfuerzo necesario para completar un elemento del backlog con otros trabajos que el equipo conoce. Para que una sesión de planning poker resulte útil, acordad una escala, elegid historias de referencia, revelad las estimaciones a la vez, comentad los motivos de las diferencias y volved a estimar después de aclarar el alcance.
Una plantilla de tablero Scrum permite mantener a la vista las historias, las referencias y las preguntas durante la conversación. Este ejemplo sigue a un equipo responsable del proceso de compra mientras estima tres elementos; uno queda sin estimar porque tiene una dependencia pendiente de resolver.
Prepara historias que se puedan comparar
Los puntos de historia expresan esfuerzo relativo: cantidad de trabajo, complejidad e incertidumbre. La explicación de Mountain Goat Software sobre los puntos de historia también incluye el trabajo necesario para cumplir la Definición de Terminado del equipo. La programación no representa toda la estimación si terminar el elemento también exige pruebas, integración o documentación.
Antes de la sesión, cada historia debe tener un resultado para el usuario y suficientes detalles de aceptación para poder debatirla. Elimina duplicados, separa resultados que no estén relacionados e identifica dependencias que puedan cambiar el trabajo. Estimar «mostrar el resumen del pedido» aporta poco si el equipo no sabe qué campos, estados y fuentes de datos incluye.
En este ejemplo, el equipo lleva tres elementos a la sesión:
- Cambiar el nombre de una dirección guardada de «Dirección 1» a una etiqueta elegida por el cliente.
- Validar una dirección postal mediante un proveedor externo y explicar al cliente los problemas encontrados.
- Mostrar los detalles de confirmación del pedido después de la compra, con campos que ya devuelve el servicio de pedidos.
Estiman las personas que harán el trabajo. El Product Owner aclara el comportamiento esperado y el alcance. Quien facilita la sesión organiza la conversación y anota las preguntas. En Scrum, los Developers son responsables de dimensionar los elementos del backlog; el marco no exige una escala de puntos ni la técnica de planning poker.
Elige historias de referencia y una sola escala
Este equipo utiliza 1, 2, 3, 5, 8 y 13. Elegid la escala antes de votar y utilizad sus valores de forma coherente. Existen otras escalas, pero cambiar de una a otra durante la misma sesión dificulta la comparación.
El equipo utiliza dos trabajos ya terminados como referencia: una edición de la etiqueta de una dirección guardada, de dos puntos, y un cambio en las opciones de entrega, de ocho puntos, que exigió un nuevo comportamiento del servicio y varios estados de error. Coloca el alcance y las condiciones de finalización junto a las cifras. La referencia es útil porque el equipo recuerda el trabajo, no porque «dos» tenga un significado por sí solo.
Pregunta si la nueva historia se parece más al pequeño cambio de edición o a la integración más amplia, y por qué. No definas un punto como un número fijo de horas. Un elemento de ocho puntos puede exigir más esfuerzo total que uno de dos sin tardar cuatro veces más en el calendario: la disponibilidad, el trabajo en paralelo y las dependencias influyen en el tiempo transcurrido.
Haz una primera votación individual
Lee un elemento y deja que el Product Owner responda a las dudas sobre su alcance antes de que alguien proponga una cifra. Después, cada persona elige un valor en privado. Reveladlos a la vez, preguntad a quienes dieron las estimaciones más baja y más alta qué trabajo incluyeron y dejad que los demás añadan supuestos que falten. Este es el proceso básico descrito en la guía de Planning Poker de Mountain Goat Software.
Supongamos que cuatro personas estiman el cambio de etiqueta de la dirección guardada. Revelan 2, 2, 3 y 3. Las estimaciones bajas suponen que solo cambia la etiqueta visible. Las altas incluyen cambios en la validación de direcciones. El Product Owner confirma que la validación y el comportamiento de entrega siguen igual. El equipo consulta su referencia de dos puntos, vuelve a votar y acuerda 2.
Nadie ha reducido una estimación para cumplir una fecha. La cifra cambia porque se ha descartado trabajo que nunca formó parte de este elemento. Anota «solo la etiqueta; la validación no cambia» junto a la estimación para que quien no estuvo en la reunión entienda el límite.
Resuelve las diferencias antes de anotar una cifra
La validación de direcciones recibe 5, 5, 8 y 13. La estimación más baja supone que un servicio existente gestiona las respuestas del proveedor. La más alta incluye el tratamiento de tiempos de espera agotados, un estado de proveedor no disponible y una decisión nueva: si el cliente puede continuar con una dirección no verificada.
El equipo ha descubierto una decisión de producto pendiente y una incógnita técnica. No calcula la media ni elige 8 por estar entre los extremos. Primero, el Product Owner debe decidir qué hacer cuando la validación no esté disponible, y una persona de ingeniería debe revisar la integración actual. El elemento vuelve al refinamiento con esas dos preguntas y sus responsables. Si hace falta, se puede planificar una investigación aparte, con una pregunta concreta que resolver, sin prometer la entrega de toda la funcionalidad.
Para la confirmación del pedido, la primera ronda es 3, 3, 5 y 5. Las estimaciones altas incluyen un recibo descargable que la historia no solicita. El Product Owner aclara que se muestran el número de pedido, los artículos, el total y la opción de entrega ya existentes; descargar un recibo es otro trabajo. Tras considerar los estados de carga y sin datos, el equipo vuelve a votar y acuerda 3.
| Elemento del proceso de compra | Primera ronda | Aclaración | Resultado registrado |
|---|---|---|---|
| Cambiar la etiqueta de una dirección guardada | 2, 2, 3, 3 | La validación de direcciones no cambia | 2 puntos |
| Validar una dirección con un proveedor | 5, 5, 8, 13 | Se desconoce el comportamiento alternativo y qué admite el servicio actual | Sin estimar; vuelve al refinamiento |
| Mostrar los detalles de confirmación | 3, 3, 5, 5 | Solo campos existentes; sin descarga de recibo | 3 puntos |
Los valores acordados proceden de una nueva conversación y votación; no son medias de la primera ronda. En particular, la escala de este equipo no contiene el 4, así que una diferencia entre 3 y 5 no se convierte automáticamente en cuatro puntos. Si las estimaciones siguen muy separadas, anota lo que falta por aclarar en vez de inventar precisión.
Registra la estimación y las preguntas pendientes
Para cada elemento estimado, guarda el valor acordado, la decisión de alcance que influyó en él y la historia de referencia utilizada. Si un elemento queda sin estimar, guarda la pregunta y quién la responderá. La historia de validación no debe aparecer con cero puntos ni desaparecer del tablero: ambas cosas ocultarían trabajo pendiente.
Las dos estimaciones acordadas suman cinco puntos, pero ese total no constituye un compromiso para el sprint. En la planificación del sprint, el equipo todavía debe considerar el Objetivo del Sprint, la capacidad disponible, las dependencias y su propio rendimiento anterior. No sumes puntos de otro equipo ni compares a las personas según cuántos puntos completan. La escala pertenece a la comprensión compartida que tiene el equipo de su trabajo.
Si el alcance pasa de «mostrar campos existentes» a «generar y descargar un recibo», revisa el elemento y su estimación. Conserva la nota de alcance anterior para que el cambio quede visible. Volver a estimar sirve cuando cambia el trabajo; modificar una cifra en silencio para que un plan pasado parezca acertado elimina información que el equipo necesita para aprender.
Organiza la conversación de estimación en Boardmix
Crea zonas para las historias de referencia, la historia actual, las estimaciones reveladas, el alcance acordado y las preguntas abiertas. Coloca las dos referencias donde todo el equipo pueda verlas. Antes de recoger los votos, muestra el resultado esperado para el usuario y las condiciones de aceptación del elemento actual.
Utiliza cartas físicas o una herramienta que permita votar en privado y revelar los valores a la vez; después, anota los valores revelados en el tablero. Escribir cifras en un lienzo compartido antes de que todos hayan elegido puede influir en quienes voten después. En esta organización, Boardmix es el espacio común para la historia y el registro de la conversación; la votación privada es una parte separada del proceso.
Abre un tablero de Boardmix para organizar las referencias y las tres historias del proceso de compra. Deja «2: solo la etiqueta», «sin estimar: aclarar qué hacer si falla el proveedor» y «3: campos de confirmación existentes» junto a sus respectivos elementos, en lugar de conservar únicamente una fila de números.
