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 práctica ágil, para conducir las reuniones en las que se estima el esfuerzo y la duración de tareas.
+{{Meta-bok|min=4}}
-James Grenning ideó este juego de planificación para evitar discusiones dilatadas que no terminan de dar conclusiones concretas.
+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.
-El modelo inicial de Grenning 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|eXtreme Programming]].
+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.
+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).
-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.
+Para estimar a nivel de producto o versión se pueden añadir valores mayores: 34, 55, 89, 144...
-Cuando se considera que éste es mayor de x [[Tiempo ideal|horas ideales]] (el tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”.
+== Error frecuente ==
-Las tareas que exceden el tamaño máximo deben descomponerse en subtareas de menor tamaño
+<div class="bok-aviso">
+'''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.
-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.
+</div>
+== Recursos ==
+<div class="bok-recurso">
-===Variante: sucesión de Fibonacci===
+🎙️ [https://open.spotify.com/episode/5cSiawMjvd1TFUpt0TPsEi '''Podcast Ep. 1: Serie Fibonacci y estimación ágil''']<span class="detalle">Scrum Manager Podcast · Spotify</span>
+</div>
-Basado en el hecho de que al aumentar el tamaño de las tareas aumenta también el margen de error, surgió una variante que consiste en emplear números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:
+<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>
-*El juego de cartas está compuesto por números en sucesión de Fibonacci.
+</div>
-*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 class="bok-recurso">
+🎙️ [https://open.spotify.com/episode/5qa41nYkK9JSmKVg0E5qt0 '''Podcast Ep. 10: Estimar o no estimar''']<span class="detalle">Scrum Manager Podcast · Spotify</span>
-Así, si por ejemplo una persona cree que el tamaño adecuado de una tarea es 6, se ve obligado a reconsiderar y, o bien aceptar que parte de la incertidumbre apreciada no es tal y levantar la carta de 5, o bien aceptar una estimación más conservadora y levantar el 8.
+</div>
+<div class="bok-recurso">
-En particular, los números de esta variación del Planning Póquer son: 0, ½, 1, 2, 3, 5, 8, 13, 21, infinito.
+📄 [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>
+</div>
-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.)
+== Véase también ==
+<div class="bok-tags">
-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.
+[[Affinity Estimating]] [[Bucket System]] [[Estimación en la pared]] [[Estimación: talla de camisetas]] [[NoEstimates]] [[Punto de historia]] [[Unidad de trabajo]]
-También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.
+</div>
+<div class="bok-ecosistema">
+<div class="texto">
-====Operativa====
+<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
-*Cada participante de la reunión tiene un juego de cartas.
+<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>
-*Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
+</div>
-*Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
+<div class="botones">
-*Cada participarte selecciona la carta, o cartas que representan su estimación, y las separa del resto, boca abajo.
+<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
-*Cuando todos han hecho su selección, se muestran boca arriba.
+<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
-*Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea debe dividirse en sub-tareas de menor tamaño.
+</div>
-*Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar 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:
+</div>
-**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.
-**Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
-**Pedir al cliente o 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 moderación, evita en la reunión 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 alcanzar consensos sin discusiones, y además resulta divertido y dinamiza la reunión.
-[[Category:Scrum I]]
 [[Category:Glosario de términos]]
+[[Category:Estimación]]
+[[Category:Prácticas ágiles]]