Estimación de póquer: Difference between revisions

Latest revision as of 15:25, 14 May 2026

⏱ 4 min de lectura · 📅 Actualizado en 2026

La estimación de póquer (Planning Poker en inglés) es una técnica de estimación ágil en la que cada miembro del equipo muestra simultáneamente una carta con su estimación de esfuerzo para una historia de usuario o unidad de trabajo. La revelación simultánea evita el efecto de anclaje y fomenta la participación de todas las voces del equipo.

Fue ideada por James Grenning para evitar discusiones dilatadas en las sesiones de estimación. Mike Cohn la popularizó en su libro Agile Estimating and Planning (2005).

Origen

El modelo inicial de Grenning consta de 8 cartas con los valores: ½, 1, 2, 3, 5, 6, 7 e infinito. Fueron desarrolladas para dar soporte a las estimaciones de versión en Extreme Programming.

Modo de aplicación

Cada participante de la reunión tiene un juego de cartas.
El propietario del producto o moderador expone la descripción de la historia dentro de un tiempo máximo; el equipo puede hacer preguntas durante un tiempo acordado.
Cada participante selecciona la carta que representa su estimación y la coloca boca abajo.
Cuando todos han hecho su selección, se revelan simultáneamente.
Si la estimación resulta "infinito" (excede el límite máximo), la historia debe dividirse en unidades de menor tamaño.
Si las estimaciones son muy dispares, quien gestiona la reunión puede optar por:
- Preguntar a las personas de las estimaciones extremas por qué. Tras escuchar las razones, repetir la estimación.
- Dejar la historia a un lado y retomar al final o en otra sesión.
- Pedir al propietario del producto que descomponga la historia.
- Tomar la estimación menor, mayor o la media.

Ventajas

Evita los atascos de análisis circular entre opciones de implementación.
Hace participar a todos los asistentes.
Reduce el tiempo de estimación de funcionalidades a escasos minutos.
Consigue consensos sin discusiones prolongadas.
Resulta dinámico y más estimulante que estimar en silencio.

Variante: sucesión de Fibonacci

En lugar de componer la cifra exacta con varias cartas, se usa una escala de Fibonacci donde cada persona levanta la carta con la cifra más aproximada a su estimación: 0, ½, 1, 2, 3, 5, 8, 13, 21, ∞

Esto obliga a tomar decisiones: si alguien estima "6", debe decidir si levanta el 5 (estimación ajustada) o el 8 (estimación conservadora). Esa decisión explicita el nivel de incertidumbre que percibe.

Es habitual añadir una carta con símbolo de interrogación (no puedo estimar ahora), una de descanso y la de infinito (historia demasiado grande).

Para estimar a nivel de producto o versión se pueden añadir valores mayores: 34, 55, 89, 144...

Error frecuente

Revelar las cartas antes de que todos hayan elegido. Si alguien muestra su carta antes de tiempo, el resto del equipo se ve influenciado por esa estimación (efecto de anclaje), lo que anula el propósito de la revelación simultánea. La disciplina de no levantar la carta hasta que el moderador lo indique es lo que hace valiosa la técnica.

Recursos

🎙️ Podcast Ep. 1: Serie Fibonacci y estimación ágilScrum Manager Podcast · Spotify

📄 Serie Fibonacci y estimación ágilScrum Manager Blog · dic 2022

🎙️ Podcast Ep. 10: Estimar o no estimarScrum Manager Podcast · Spotify

📄 Técnicas de estimación ágil: tres estrategiasScrum Manager Blog · jul 2023

Véase también

Affinity Estimating Bucket System Estimación en la pared Estimación: talla de camisetas NoEstimates Punto de historia Unidad de trabajo

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.

Buscar convocatorias

Club Agile

@@ Line 1: / Line 1: @@
-Es una de las metodologías de estimación ágil más utilizada. Fue desarrollada por James Groenning, quien ideó este juego de planificación como ayuda para conducir la reunión de estimación.
+{{Meta-bok|min=4}}
+La '''estimación de póquer''' (''Planning Poker'' en inglés) es una técnica de estimación ágil en la que cada miembro del equipo muestra simultáneamente una carta con su estimación de esfuerzo para una [[Historia de usuario|historia de usuario]] o [[Unidad de trabajo|unidad de trabajo]]. La revelación simultánea evita el efecto de anclaje y fomenta la participación de todas las voces del equipo.
+Fue ideada por James Grenning para evitar discusiones dilatadas en las sesiones de estimación. Mike Cohn la popularizó en su libro ''Agile Estimating and Planning'' (2005).
+== Origen ==
+El modelo inicial de Grenning consta de 8 cartas con los valores: ½, 1, 2, 3, 5, 6, 7 e infinito. Fueron desarrolladas para dar soporte a las estimaciones de versión en [[Extreme programming|Extreme Programming]].
+== Modo de aplicación ==
+* Cada participante de la reunión tiene un juego de cartas.
+* El [[Propietario del producto|propietario del producto]] o moderador expone la descripción de la historia dentro de un tiempo máximo; el equipo puede hacer preguntas durante un tiempo acordado.
+* Cada participante selecciona la carta que representa su estimación y la coloca boca abajo.
+* Cuando todos han hecho su selección, se revelan simultáneamente.
+* Si la estimación resulta "infinito" (excede el límite máximo), la historia debe dividirse en unidades de menor tamaño.
+* Si las estimaciones son muy dispares, quien gestiona la reunión puede optar por:
+** Preguntar a las personas de las estimaciones extremas por qué. Tras escuchar las razones, repetir la estimación.
+** Dejar la historia a un lado y retomar al final o en otra sesión.
+** Pedir al propietario del producto que descomponga la historia.
+** Tomar la estimación menor, mayor o la media.
+=== Ventajas ===
+* Evita los atascos de análisis circular entre opciones de implementación.
+* Hace participar a todos los asistentes.
+* Reduce el tiempo de estimación de funcionalidades a escasos minutos.
+* Consigue consensos sin discusiones prolongadas.
+* Resulta dinámico y más estimulante que estimar en silencio.
+=== Variante: sucesión de Fibonacci ===
+En lugar de componer la cifra exacta con varias cartas, se usa una escala de Fibonacci donde cada persona levanta la carta con la cifra más aproximada a su estimación: '''0, ½, 1, 2, 3, 5, 8, 13, 21, ∞'''
+<br>
+[[File:Poker fibonacci.png|350px|center]]
+<br>
+Esto obliga a tomar decisiones: si alguien estima "6", debe decidir si levanta el 5 (estimación ajustada) o el 8 (estimación conservadora). Esa decisión explicita el nivel de incertidumbre que percibe.
-El modelo inicial de Groenning consta de 8 cartas, con los siguientes valores: ½, 1, 2, 3, 5, 6, 7 e infinito. Las mismas fueron desarrolladas para dar soporte a las estimaciones de versión en eXtreme Programming, con equipos que:
+Es habitual añadir una carta con símbolo de interrogación (no puedo estimar ahora), una de descanso y la de infinito (historia demasiado grande).
-*emplean como unidad de esfuerzo los “días de trabajo” de cada par de programadores (entendiendo que XP trabaja con programación de a pares); y
+Para estimar a nivel de producto o versión se pueden añadir valores mayores: 34, 55, 89, 144...
-*trabajan con tareas de tamaño máximo de 10 días (las tareas de mayor tamaño se descomponen en sub-tareas hasta que éstas tienen estimaciones máximas de 10 días).
-El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.
-Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “¥”.
+== Error frecuente ==
+<div class="bok-aviso">
-Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.
+'''Revelar las cartas antes de que todos hayan elegido.''' Si alguien muestra su carta antes de tiempo, el resto del equipo se ve influenciado por esa estimación (efecto de anclaje), lo que anula el propósito de la revelación simultánea. La disciplina de no levantar la carta hasta que el moderador lo indique es lo que hace valiosa la técnica.
+</div>
-Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo que el equipo considera más apropiado, respetando los principios siguientes:
+== Recursos ==
+<div class="bok-recurso">
-*No definir tareas demasiado grandes, porque entorpece la precisión de las estimaciones y la identificación de riesgos.
+🎙️ [https://open.spotify.com/episode/5cSiawMjvd1TFUpt0TPsEi '''Podcast Ep. 1: Serie Fibonacci y estimación ágil''']<span class="detalle">Scrum Manager Podcast · Spotify</span>
-*No definir tareas cuya duración (en puntos o tiempo) resulte inferior a medio día ideal de trabajo.
+</div>
-*Utilizar la misma unidad de medida (puntos de historias, días u horas) en todos los gráficos y pilas.
+<div class="bok-recurso">
+📄 [https://www.scrummanager.com/blog/2022/12/podcast-serie-fibonacci-estimacion-agil/ '''Serie Fibonacci y estimación ágil''']<span class="detalle">Scrum Manager Blog · dic 2022</span>
+</div>
-===Variante: sucesión de Fibonacci===
+<div class="bok-recurso">
+🎙️ [https://open.spotify.com/episode/5qa41nYkK9JSmKVg0E5qt0 '''Podcast Ep. 10: Estimar o no estimar''']<span class="detalle">Scrum Manager Podcast · Spotify</span>
-Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:
+</div>
+<div class="bok-recurso">
-*El juego de cartas está compuesto por números de la sucesión de Fibonacci.
+📄 [https://www.scrummanager.com/blog/2023/07/tecnicas-de-estimacion-agil-tres-metodos/ '''Técnicas de estimación ágil: tres estrategias''']<span class="detalle">Scrum Manager Blog · jul 2023</span>
-*La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.
+</div>
+== Véase también ==
-En particular, los números de esta variación del Planning Póquer son: 0, ½, 1, 2, 3, 5, 8, 13, 21, ¥.
+<div class="bok-tags">
+[[Affinity Estimating]] [[Bucket System]] [[Estimación en la pared]] [[Estimación: talla de camisetas]] [[NoEstimates]] [[Punto de historia]] [[Unidad de trabajo]]
-Si se quiere emplear la planificación de póquer para estimar requisitos a nivel de producto o de versión (funcionalidades, temas) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144, etc.)
+</div>
+<div class="bok-ecosistema">
-Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación.
+<div class="texto">
+<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
-También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso; así como otra carta con “infinito” para representar tareas “demasiado grandes”, que requieren ser divididas en tareas más pequeñas.
+<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
+</div>
-===Funcionamiento===
+<div class="botones">
-*Cada participante de la reunión tiene un juego de cartas.
+<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
-*Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el  propietario del producto expone la descripción.
+<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
-*Cada participante selecciona la carta y las separa del resto, boca abajo.
+</div>
-*Cuando todos han hecho su selección, se muestran boca arriba.
+</div>
-*Si la estimación resulta “infinito”, por sobre¬pasar el límite máximo establecido, la tarea debe dividirse en sub-tareas de menor tamaño.
+[[Category:Glosario de términos]]
-*Si las estimaciones resultan muy dispares, el moderador de la reunión, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar, puede optar por:
+[[Category:Estimación]]
-**Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimación.
+[[Category:Prácticas ágiles]]
-**Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan que-dado pendientes.
-**Pedir al propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
-**Tomar la estimación menor, mayor, o la media.
-Este protocolo de reunión evita los atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcan¬zar consensos sin discusiones, y además resulta divertido y dinamiza la reunión.
-[[Category:Scrum I]]