Sesión de ejemplo de Scrum Poker: 5 historias, de principio a fin

La forma más rápida de entender Scrum Poker es ver cómo se desarrolla una sesión real - no cinco reglas aisladas, sino un equipo trabajando en un backlog real, desacuerdos incluidos. Esta página recorre una sesión completa: cuatro desarrolladores, cinco historias, un facilitador, y termina con el historial de rondas exportado. Para la teoría detrás de todo esto, consulta la guía completa de Scrum Poker o la referencia de reglas.

El equipo: Priya (facilitadora), Sam, Jordan y Alex - cuatro desarrolladores estimando el equivalente a un sprint de elementos refinados del backlog con la baraja Fibonacci estándar.

Historia 1: Añadir un botón de "reenviar correo de confirmación"

Priya lee la historia y sus criterios de aceptación en voz alta. Todos votan en privado.

Ronda 1: Sam 2, Jordan 3, Alex 2, Priya 3.

Una dispersión ajustada - el equipo anota 3 (redondeando al valor más alto de los dos valores agrupados, una convención habitual de la casa) y sigue adelante sin discusión. Sin valor atípico no hay nada que discutir.

Historia 2: Permitir que los usuarios exporten su historial de pedidos como CSV

Ronda 1: Sam 3, Jordan 3, Alex 8, Priya 3.

Alex es el valor atípico. Priya le pide a Alex que explique primero: "Nuestra tabla de pedidos no pagina más allá de 500 filas en la consulta de exportación actualmente - algunos clientes empresariales tienen más de 10.000 pedidos, así que esto necesita una exportación en streaming, no la consulta simple que usaron las otras historias similares." Sam no había considerado cuentas tan grandes; Jordan señala que la corrección de paginación probablemente sea una utilidad compartida que también querrán usar en otros lugares.

Discusión, 90 segundos. El equipo coincide en que la preocupación por el streaming es real y la incorpora al alcance de la historia en lugar de tratarla como una separada.

Ronda 2: Sam 5, Jordan 5, Alex 8, Priya 5.

Más ajustado, pero Alex sigue viendo más riesgo que los demás. Priya lo fija en 5 con una nota para vigilar el rendimiento de la consulta durante la implementación - una resolución saludable, no un promedio forzado.

Historia 3: Integrar el flujo de pago de un nuevo proveedor

Ronda 1: Sam 5, Jordan 13, Alex 8, Priya 5.

Una dispersión real. Jordan explica: "Revisé su documentación ayer - el entorno sandbox no permite probar en absoluto los flujos de tarjeta rechazada, así que estaríamos lanzando esa ruta de error sin haberla probado nunca contra su sandbox." Eso es una incertidumbre genuina, no solo precaución.

Discusión, tres minutos. El equipo decide que una breve investigación (spike) para confirmar la limitación del sandbox y encontrar una solución alternativa (o aceptar la brecha de pruebas con un plan de monitoreo) tiene más sentido que estimar alrededor de una pregunta abierta.

Resultado: aparcada para una investigación (spike), no se vuelve a votar. Forzar un número aquí habría sido teatro - lo honesto es investigar primero. Consulta estimar spikes y tareas de investigación para ver cómo encaja esto en un sprint.

Historia 4: Corregir un error de redondeo en el cálculo del total del carrito

Ronda 1: Sam 2, Jordan 2, Alex 3, Priya 2.

Casi unánime. La causa ya está diagnosticada (un problema de punto flotante en un paso de cálculo específico), así que esto se estima como una corrección pequeña y bien entendida. 2, sin necesidad de discusión.

Historia 5: Añadir permisos basados en roles al panel de administración

Ronda 1: Sam 13, Jordan 8, Alex 21, Priya 13.

Todos los votos son altos, y la dispersión en sí misma es una señal. Priya le pregunta primero a Alex (el más alto): "Esto toca tres roles, cinco pantallas, y tanto la capa de API como la interfaz de usuario - no creo que esto sea una sola historia." Jordan está de acuerdo pero mentalmente la había dimensionado más pequeña, limitada a los cambios de API.

Discusión, dos minutos. En lugar de volver a votar, el equipo coincide en que la historia debería dividirse - por rol, empezando con permisos solo de administrador, luego editor, luego visualizador. Consulta dividir historias de usuario para la estimación para ver el patrón.

Resultado: dividida antes de estimar, no forzada a un número. Un voto universalmente alto suele ser una señal de división, no una señal de "digamos que es un 13 y sigamos adelante".

El historial de rondas exportado

Al final de la sesión, Priya exporta el historial de rondas como CSV - la misma exportación que produce una sala real de OneMorePoint, útil para la discusión en retrospectivas y la calibración futura:

La integración de pagos de la historia 2 se aparcó para una investigación (spike) y la historia 5 se dividió antes de que se fijara una estimación final, así que ninguna aparece en el promedio exportado hasta que se vuelvan a estimar como historias más pequeñas y listas - exactamente para eso sirve el historial: un registro escrito de lo que realmente se dimensionó, no un número forzado para lo que no se dimensionó.

Lo que esta sesión realmente demuestra

Dos de cinco historias - un 40% real - no obtuvieron un número limpio en la primera ronda, y ninguna se resolvió promediando ni con el facilitador eligiendo un compromiso. Una se dividió, otra se aparcó para una investigación (spike). Eso no es una sesión fallida; es la técnica funcionando como se pretende. El valor de Scrum Poker no está en los números que produce en las historias fáciles (cualquier método acertaría con la historia 1 y la historia 4) - está en lo que ocurre en las historias 2, 3 y 5, donde el voto revela un desacuerdo que un solo estimador, o un promedio silencioso, habría pasado por alto completamente.

Ejecuta esto con tu propio backlog

Crea una sala gratis, extrae cinco historias reales de tu propio backlog, y descubre cuáles resultan tener desacuerdo oculto. Sin registro, todos los tipos de baraja incluidos, y el historial de rondas se exporta de la misma manera que se muestra arriba.