Planning Poker: La Guía Completa de Estimación Ágil para Equipos Scrum

Planning Poker es una técnica de estimación basada en consenso donde cada miembro del equipo Scrum selecciona privadamente una carta que representa su estimación, y luego todas las cartas se revelan simultáneamente para prevenir sesgos. Creado por James Grenning en 2002 y luego popularizado por Mike Cohn, se ha convertido en el método de estimación más utilizado en Agile, y por buenas razones.

Este es el problema que resuelve. Sin Planning Poker, las sesiones de estimación se convierten en uno de dos modos de falla: o la persona más senior habla primero y todos se anclan a su número, o el equipo discute sin cesar sin llegar a un acuerdo. Planning Poker soluciona ambos. La revelación simultánea elimina el sesgo de anclaje, y las rondas de discusión estructuradas impulsan conversaciones productivas sobre complejidad, incógnitas y riesgos.

Ya sea que estés dirigiendo Sprint Planning para un nuevo equipo Scrum o buscando mejorar la precisión de estimación en un equipo experimentado, esta guía cubre todo, desde el proceso básico hasta estrategias avanzadas de facilitación, errores comunes y cuándo es mejor usar un enfoque diferente completamente.

Respuesta Rápida: Planning Poker de un Vistazo

Aspecto	Detalles
Qué es	Técnica de estimación basada en consenso usando cartas con valores
Creado por	James Grenning (2002), popularizado por Mike Cohn
Valores de Cartas	Fibonacci Modificada: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ☕
Tiempo por Historia	2-5 minutos (incluyendo rondas de discusión)
Quién Participa	Solo los Developers estiman; el Product Owner aclara pero no vota
Cuándo Usar	Sprint Planning, sesiones de Backlog Refinement
Beneficio Clave	Elimina el sesgo de anclaje, impulsa entendimiento compartido
Precisión	La investigación muestra que es notablemente más precisa que las estimaciones individuales

¿Qué es Planning Poker?

Planning Poker es una técnica de estimación Ágil donde el Development Team asigna story points a elementos del Product Backlog a través de un proceso estructurado basado en cartas. Cada miembro del equipo tiene un mazo de cartas con números de la secuencia de Fibonacci, selecciona su estimación privadamente, y luego todos la revelan al mismo tiempo.

¿La clave? La revelación simultánea. Esta única decisión de diseño elimina el efecto de anclaje, el sesgo cognitivo bien documentado donde las personas ajustan su pensamiento según el primer número que escuchan.

Orígenes e Historia

Planning Poker tiene sus raíces en la técnica Wideband Delphi desarrollada en la Corporación RAND en la década de 1940. Ese método ya utilizaba estimación independiente seguida de discusión grupal, pero no estaba diseñado para el ritmo rápido del desarrollo de software.

En 2002, James Grenning adaptó el concepto a lo que ahora llamamos Planning Poker. Publicó "Planning Poker, or How I Learned to Stop Worrying and Love the Estimate" - tomando prestado el título de Kubrick - y describió una técnica ligera que encajaba naturalmente en los Sprints Ágiles.

Mike Cohn luego popularizó el método a través de su libro de 2005 Agile Estimating and Planning, que se convirtió en la referencia estándar para prácticas de estimación Ágil. Hoy, Planning Poker es el método de estimación dominante en equipos Ágiles en todo el mundo.

Por Qué Funciona: La Ciencia Detrás

Tres mecanismos hacen efectivo a Planning Poker:

1. Prevención del Sesgo de Anclaje La investigación de Kahneman y Tversky demostró que los humanos ponderan fuertemente la primera información que reciben. En reuniones de estimación tradicionales, la primera persona que habla "ancla" las estimaciones de todos los demás. La revelación simultánea de Planning Poker evita esto completamente.

2. Sabiduría de las Multitudes Cuando los individuos estiman independientemente antes de compartir, la estimación grupal tiende a ser más precisa que la de cualquier persona individual. Este efecto - documentado por Surowiecki y otros - requiere juicio independiente seguido de agregación. Planning Poker proporciona exactamente eso.

3. Discusión Forzada de Valores Atípicos Cuando las estimaciones divergen (digamos, un 3 y un 13 para la misma historia), el equipo debe explicar su razonamiento. Estas conversaciones frecuentemente revelan suposiciones ocultas, requisitos perdidos o diferentes interpretaciones de la historia. La discusión en sí misma a menudo es más valiosa que el número final.

El Proceso de Planning Poker: Paso a Paso

Aquí está el proceso completo, desde la configuración hasta la estimación final.

Paso 1: Presentar la User Story

El Product Owner lee la user story en voz alta y explica:

• Qué entrega la historia (valor para el usuario)
• Criterios de aceptación (cómo sabemos que está terminada)
• Contexto - por qué esta historia importa ahora

Mantenlo breve. El objetivo es entendimiento compartido, no una revisión de especificaciones. Dos a tres minutos es típicamente suficiente.

Paso 2: Hacer Preguntas Aclaratorias

El equipo hace preguntas. Esto es crítico - no te apresures. Las preguntas comunes incluyen:

• "¿Esto incluye la API del backend, o solo la UI?"
• "¿Hay patrones existentes que podemos seguir?"
• "¿Qué pasa si el servicio externo no está disponible?"

El Product Owner responde lo que puede. Para preguntas técnicas fuera de su alcance, los miembros del equipo con experiencia relevante participan.

Paso 3: Seleccionar Cartas Privadamente

Cada miembro del equipo selecciona una carta sin mostrársela a nadie. Sin discusión, sin mirar, sin anunciar. Esta independencia es lo que hace funcionar la técnica.

Los miembros del equipo deben considerar:

• Complejidad - ¿Cuántas partes móviles? ¿Qué tan interconectadas?
• Incertidumbre - ¿Qué tan bien entendemos los requisitos y la tecnología?
• Esfuerzo - ¿Cuánto trabajo está involucrado, aproximadamente?

Paso 4: Revelar Simultáneamente

En una cuenta ("3, 2, 1, ¡voltea!"), todos muestran sus cartas al mismo tiempo.

Si las estimaciones son cercanas (dentro de un número de Fibonacci), toma el valor más alto y continúa. No es necesario discutir el acuerdo - ahorra tiempo para las historias donde las opiniones difieren.

Paso 5: Discutir las Diferencias

Cuando las estimaciones divergen, los estimadores más alto y más bajo explican su razonamiento. Aquí es donde vive el valor real.

Descubrimientos típicos durante la discusión:

• "No me di cuenta de que necesitamos construir eso desde cero" - Alguien asumió una librería existente; alguien más sabe que no existe
• "Esa integración es en realidad sencilla" - La persona que lo hizo antes comparte que es un patrón conocido
• "Estamos olvidando la migración" - Surge un requisito oculto

El Scrum Master facilita, asegurando que todos sean escuchados y la conversación se mantenga productiva.

Paso 6: Re-Estimar Hasta el Consenso

Después de la discusión, el equipo re-estima. Usualmente una o dos rondas adicionales producen consenso.

¿Qué cuenta como consenso? No todos necesitan estar de acuerdo en el mismo número exacto. Si tienes cuatro 5s y un 8, está bien - ve con 5 u 8 dependiendo de la confianza del equipo. La conversación ya ocurrió, que es lo que importa.

Limita el tiempo de cada historia a 5 minutos. Si el consenso no emerge, ya sea:

• Toma la estimación más alta (más seguro)
• Difiere la historia para más investigación (spike)
• Divide la historia en piezas más pequeñas

Valores de las Cartas de Planning Poker Explicados

La Escala de Fibonacci Modificada

La mayoría de los equipos usan este conjunto: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

¿Por qué Fibonacci y no 1-10? Las brechas crecientes entre números reflejan cómo la incertidumbre aumenta con el tamaño. Puedes notar la diferencia entre una historia de 2 puntos y una de 3 puntos. ¿Pero afirmar que algo es 47 vs. 48? Esa es una precisión falsa que nadie necesita.

Puntos	Lo Que Significa	Duración Aproximada
0	Ya está hecho o cambio de configuración trivial	Minutos
½	Diminuto - cambio de texto, corrección simple	Menos de una hora
1	Pequeño, tarea bien entendida	Pocas horas
2	Pequeño con complejidad menor	Medio día
3	Medio, enfoque claro	Aproximadamente un día
5	Medio-grande, algunas incógnitas	1-2 días
8	Grande, múltiples componentes	2-3 días
13	Muy grande, incógnitas significativas	3-5 días
20+	Demasiado grande - debería dividirse	Considerar dividir

Cartas Especiales

• ? (Signo de Interrogación): "No tengo suficiente información para estimar." Esto no es una excusa - señala que la historia necesita más refinamiento antes de que el equipo pueda comprometerse.
• ☕ (Taza de Café): "Necesito un descanso." Las sesiones largas de estimación causan fatiga. Honra esta carta.
• ∞ (Infinito): "Esta historia es demasiado grande o vaga para estimarla." Es hora de dividirla.

Escalas Alternativas

Algunos equipos prefieren escalas diferentes:

• Tallas de Camiseta: XS, S, M, L, XL - buenas para estimación de roadmap de alto nivel
• Potencias de 2: 1, 2, 4, 8, 16, 32 - más limpias para algunos equipos, aunque los saltos se sienten poco naturales
• Cinco Dedos: Levanta 1-5 dedos - no se necesitan cartas, funciona en configuraciones casuales

La escala de Fibonacci sigue siendo la opción más popular porque logra el equilibrio adecuado entre precisión y reconocimiento de incertidumbre.

Planning Poker vs Otras Técnicas de Estimación

Aspecto	Planning Poker	T-Shirt Sizing	Affinity Estimation	Estimación Individual
Velocidad por Elemento	2-5 minutos	30-60 segundos	10-20 segundos	15-30 segundos
Mejor Tamaño de Lote	10-20 historias	20-50 historias	50-200 historias	Cualquiera
Precisión	Alta	Media	Media	Baja
Alineación del Equipo	Alta (impulsada por discusión)	Media	Media-Alta	Ninguna
Protección contra Sesgos	Fuerte (revelación simultánea)	Moderada	Moderada	Ninguna
Mejor Para	Sprint planning, refinamiento	Dimensionamiento de roadmap, equipos nuevos	Triage de backlog grande	Triage individual rápido
Seguimiento de Velocity	Directo (numérico)	Requiere conversión	Requiere conversión	Directo

Progresión común: Affinity estimation para el backlog inicial (100+ historias) → T-shirt sizing para roadmap trimestral → Planning Poker para historias a nivel de Sprint.

Ejecutar Planning Poker para Equipos Remotos

Planning Poker fue diseñado para equipos colocados con cartas físicas. Pero la mayoría de los equipos hoy están distribuidos. Aquí está cómo hacer que funcione.

Sesiones Remotas Síncronas

• Video encendido. Ver rostros ayuda a leer incertidumbre y compromiso.
• Comparte pantalla de la historia. Todos miran los mismos criterios de aceptación simultáneamente.
• Usa cartas digitales. Las herramientas manejan la revelación simultánea automáticamente.
• Limita el tiempo estrictamente. La fatiga remota llega más rápido - mantén las sesiones bajo 60 minutos.
• Silencio durante la selección privada. Previene anclaje verbal ("hmm, esta es grande...").

Planning Poker Asíncrono

Para equipos que abarcan muchas zonas horarias, la estimación asíncrona puede funcionar:

1. El Product Owner publica la historia con contexto en un canal compartido
2. Los miembros del equipo envían estimaciones dentro de una ventana de 24 horas
3. Si las estimaciones convergen, registra el consenso
4. Si las estimaciones divergen, programa una discusión síncrona de 15 minutos solo para esas historias

Este enfoque híbrido maneja 70-80% de las historias asincrónicamente, reservando tiempo síncrono para las contenciosas.

Herramientas Digitales Populares

Herramienta	Nivel Gratuito	Integración Jira	Soporte Async	Mejor Para
Parabol	Sí	Sí	Sí	Equipos remotos primero
Planning Poker Online	Sí	No	No	Sesiones rápidas
Scrum Poker (plugin Jira)	Prueba	Nativo	No	Equipos pesados en Jira
Miro/Mural Templates	Sí	No	Sí	Pensadores visuales
Scrumpy Poker	Sí	Sí	No	Configuración simple

Errores Comunes de Planning Poker

Ocho errores que sabotean las sesiones de estimación - y cómo arreglar cada uno.

Error 1: El Product Owner Vota en las Estimaciones

Cómo se ve: El PO toma cartas y participa junto a los Developers.

Por qué es un problema: Incluso los POs bien intencionados crean presión implícita. Si el PO levanta un 3, los developers que pensaron 8 podrían autocensurarse para no parecer lentos.

Solución: El Product Owner presenta la historia, responde preguntas y observa. No vota. Punto. Si tu PO se resiste, señálale la Guía de Scrum - solo los Developers estiman el trabajo.

Error 2: Tratar los Story Points como Compromisos de Tiempo

Cómo se ve: "¿Dijiste que esto era un 5? Eso significa que debería estar hecho para el miércoles."

Por qué es un problema: Los story points miden complejidad, incertidumbre y esfuerzo combinados - no tiempo de calendario. Convertir puntos a horas derrota todo el propósito.

Solución: Usa velocity (promedio de story points completados por Sprint) para pronosticar fechas de entrega. Nunca conviertas story points individuales a horas.

Error 3: Promediar en Lugar de Discutir

Cómo se ve: "Obtuvimos 3, 5, 5, 8, 13. El promedio es 6.8, llamémoslo 8."

Por qué es un problema: La persona que dijo 13 podría saber sobre una dependencia oculta. La persona que dijo 3 podría conocer un atajo. Promediar descarta esta información por completo.

Solución: Siempre haz que los estimadores más alto y más bajo expliquen su razonamiento antes de re-estimar. Los valores atípicos a menudo contienen la información más valiosa.

Error 4: Sesiones Maratón de Estimación

Cómo se ve: Sesiones de Planning Poker de cuatro horas donde el equipo estima 40+ historias.

Por qué es un problema: La precisión de estimación cae significativamente después de 60-90 minutos. Para la historia 30, las personas solo están jugando cartas al azar para terminar.

Solución: Limita las sesiones a 60-90 minutos y 15-20 historias. Haz backlog refinement continuo para que nunca necesites sesiones maratón.

Error 5: Sin Historias de Referencia

Cómo se ve: Cada estimación comienza desde cero. "¿Esto es un 5? ¿Cómo se siente un 5 siquiera?"

Por qué es un problema: Sin calibración, el mismo equipo podría estimar historias similares como 3 una semana y 8 la siguiente. Velocity se vuelve impredecible.

Solución: Mantén un "póster de historias de referencia" - 2-3 historias completadas para cada número de Fibonacci. Antes de cada sesión, recuerda al equipo: "Recuerden, nuestra referencia de 5 puntos fue la refactorización del formulario de pago."

Error 6: Ignorar la Carta de Café

Cómo se ve: Alguien juega la carta ☕ y el facilitador dice "Tomaremos un descanso después de estas próximas cinco historias."

Por qué es un problema: Un equipo fatigado produce malas estimaciones. La carta de café existe por una razón.

Solución: Honra las solicitudes de descanso inmediatamente. Es mejor perder 10 minutos en un descanso que desperdiciar un Sprint en malas estimaciones.

Error 7: Re-Estimar Historias Completadas

Cómo se ve: "Ese 5-pointer en realidad tomó una semana completa. Cambiémoslo a 13."

Por qué es un problema: Cambiar estimaciones históricas corrompe los datos de velocity. Tu velocity debe reflejar cuánto pensaste que podías hacer vs. cuánto realmente hiciste - esa brecha es información útil.

Solución: Mantén las estimaciones originales. Discute las estimaciones erróneas en la Sprint Retrospective para mejorar la precisión futura.

Error 8: Permitir Conversaciones Paralelas Durante la Selección de Cartas

Cómo se ve: Developers charlando sobre la historia mientras eligen cartas. "Sí, creo que esta es bastante grande..."

Por qué es un problema: Esto reintroduce el sesgo de anclaje por la puerta trasera. Incluso comentarios casuales influencian la selección de cartas.

Solución: Impone silencio durante la selección de cartas. El facilitador dice "Solo cartas, sin hablar" antes de cada ronda.

Cuándo NO Usar Planning Poker

Planning Poker no es universal. Omítelo cuando:

• Desarrollador solo: No puedes jugar poker solo. Usa estimación basada en tiempo en su lugar.
• Todas las historias son de complejidad similar: Si estás quemando 50 correcciones de bugs similares, solo cuéntalos. No se necesitan cartas.
• Historias de Spike/investigación: Limita el tiempo de estas ("pasa 4 horas investigando") en lugar de estimar en puntos.
• Incidentes de producción: Responde primero, estima nunca. Los incidentes no son trabajo planificado.
• Historias muy pequeñas (todas 1-2 puntos): Si tu equipo consistentemente está de acuerdo en que las historias son diminutas, estímalas en lote.
• Equipos de flujo continuo Kanban: Los equipos que usan Kanban puro a menudo omiten los story points por completo y usan métricas de cycle time en su lugar.

Usa Affinity Estimation en su lugar cuando tengas 50+ historias para estimar en una sola sesión. Usa T-shirt sizing cuando los stakeholders necesiten dimensionamiento aproximado para conversaciones de roadmap.

Madurez de Planning Poker: De Principiante a Avanzado

Los equipos no dominan Planning Poker de la noche a la mañana. Así es como típicamente se ve el viaje.

Etapa 1: Aprendiendo las Reglas (Sprints 1-3)

Qué esperar:

• Alta varianza de estimación (dispersiones de 1 a 13 en la misma historia)
• Muchas rondas de discusión (3-4 por historia)
• Las sesiones se alargan (las historias toman 10+ minutos cada una)
• El equipo todavía piensa en horas, no complejidad relativa

Enfócate en:

• Sentirte cómodo con los números de Fibonacci
• Establecer tus primeras 3-5 historias de referencia
• Mantener las discusiones productivas (no argumentativas)
• Construir seguridad psicológica para que los miembros junior hablen

Etapa 2: Encontrando Tu Ritmo (Sprints 4-10)

Qué esperar:

• La varianza de estimación se reduce (dispersión típica de 1-2 números de Fibonacci)
• La mayoría de las historias alcanzan consenso en 1-2 rondas
• Las sesiones se vuelven predecibles (2-4 minutos por historia)
• Velocity se estabiliza lo suficiente para pronósticos básicos

Enfócate en:

• Expandir tu biblioteca de historias de referencia
• Detectar historias que necesitan dividirse antes de la estimación
• Conectar estimaciones a velocity para planificación de releases
• Probar estimación asíncrona para historias sencillas

Etapa 3: Confianza en la Estimación (Sprint 11+)

Qué esperar:

• Consenso de una sola ronda en la mayoría de las historias
• El equipo naturalmente identifica historias que necesitan dividirse
• Las sesiones de estimación se sienten ligeras y rápidas
• Velocity es estable y predecible

Enfócate en:

• Calibración continua - actualiza las historias de referencia cada trimestre
• Pronósticos probabilísticos usando datos históricos de velocity
• Mentorear nuevos miembros del equipo usando prácticas establecidas
• Considerar si algunos tipos de historias pueden omitir la estimación formal por completo

Ejemplos de la Industria

Planning Poker se adapta a diferentes contextos. Así es como los equipos en varias industrias lo usan.

Equipos de Productos SaaS

Historia típica: "Como administrador, quiero configurar SSO vía SAML para que los clientes empresariales puedan usar su proveedor de identidad."

Consideraciones de estimación: Complejidad de integración de API, requisitos de revisión de seguridad, implicaciones multi-tenant, necesidades de documentación.

Patrón común: La mayoría de las historias caen en el rango 3-8. Las historias de infraestructura (migraciones de base de datos, cambios CI/CD) a menudo obtienen 13+ debido a coordinación entre equipos.

Software de Salud

Historia típica: "Como clínico, quiero ver el historial de medicación del paciente con advertencias de interacción."

Consideraciones de estimación: Requisitos de cumplimiento HIPAA, registro de auditoría, controles de acceso a datos, impacto en flujo de trabajo clínico. Las historias que tocan Información de Salud Protegida (PHI) típicamente obtienen estimaciones más altas debido a verificación de cumplimiento.

Patrón común: Los equipos agregan "revisión de cumplimiento" a su Definition of Done, lo que infla las estimaciones vs. industrias no reguladas. Una historia que podría ser un 5 en otro lugar es un 8 aquí.

Plataformas de E-Commerce

Historia típica: "Como comprador, quiero reordenar con un clic desde mi historial de pedidos."

Consideraciones de estimación: Integración de procesamiento de pagos (cumplimiento PCI), verificaciones de disponibilidad de inventario, recálculo de precios, responsividad móvil.

Patrón común: Las historias de características van de 5-13 puntos. Las historias de optimización de rendimiento son más difíciles de estimar porque el alcance depende de los resultados de perfilado - estas a menudo se convierten en spikes primero.

Desarrollo de Aplicaciones Móviles

Historia típica: "Como usuario, quiero recibir notificaciones push de actualizaciones de estado de pedido."

Consideraciones de estimación: Diferencias entre iOS y Android, integración de servicio de notificaciones push, manejo de procesos en segundo plano, gestión de preferencias de notificación, cumplimiento de guías de app store.

Patrón común: Las historias "misma característica, dos plataformas" a menudo necesitan estimaciones separadas. Una historia de 5 puntos en Android podría ser 8 puntos en iOS (o viceversa) dependiendo de desafíos específicos de la plataforma.

FinTech / Banca

Historia típica: "Como usuario, quiero configurar transferencias recurrentes entre mis cuentas."

Consideraciones de estimación: Procesamiento de transacciones, integración de detección de fraude, cumplimiento regulatorio (SOC 2, PCI-DSS), requisitos de encriptación, registro de auditoría.

Patrón común: Los requisitos de cumplimiento y seguridad significan que las historias de FinTech consistentemente estiman más alto. Los equipos a menudo mantienen historias de referencia separadas para características "pesadas en cumplimiento" vs. "estándar".

Gobierno / Sector Público

Historia típica: "Como ciudadano, quiero enviar mi solicitud de permiso en línea."

Consideraciones de estimación: Cumplimiento de accesibilidad Sección 508, requisitos de seguridad FISMA, soporte multi-idioma, integración de sistemas heredados.

Patrón común: La integración de sistemas heredados es el comodín. Los equipos rápidamente aprenden a agregar un "impuesto de integración heredada" a sus estimaciones cuando las APIs están mal documentadas o son poco confiables.

Mejores Prácticas para Sesiones Efectivas

Antes de la sesión:

• Refina historias antes de la estimación - las historias vagas producen estimaciones vagas
• Comparte historias 24 horas antes para que el equipo pueda pensar con anticipación
• Publica historias de referencia donde todos puedan verlas

Durante la sesión:

• Limita el tiempo de cada historia a 5 minutos (incluyendo discusión)
• Deja que los estimadores más alto y más bajo hablen primero
• Si no está claro, difiere - no fuerces un número
• Rastrea qué historias tuvieron alta varianza (revisa en retro)

Después de la sesión:

• Registra estimaciones en tu herramienta de backlog inmediatamente
• Anota cualquier historia diferida para más información
• Marca historias con varianza alta persistente para el Product Owner

Consejos de facilitación:

• Rota el rol de facilitador para construir propiedad compartida
• Usa humor - Planning Poker debe sentirse como un juego, no una reunión
• Observa "fatiga de estimación" - sesiones más cortas y frecuentes vencen maratones
• Los nuevos miembros del equipo deberían observar 1-2 sesiones antes de participar

Conclusión

Planning Poker funciona porque respeta cómo realmente piensan los humanos. La revelación simultánea previene el sesgo de anclaje. Las rondas de discusión revelan complejidad oculta. La escala de Fibonacci reconoce que las tareas más grandes tienen más incertidumbre.

Puntos clave:

1. La revelación simultánea es innegociable - es el mecanismo que previene el sesgo
2. La discusión importa más que el número - la conversación revela riesgos y suposiciones
3. Solo los Developers estiman - el Product Owner aclara pero no vota
4. Usa historias de referencia para calibración - "¿Cómo se siente realmente un 5 en este equipo?"
5. Limita el tiempo de cada historia a 5 minutos - si no puedes alcanzar consenso, la historia necesita dividirse o un spike
6. No conviertas puntos a horas - usa velocity para pronósticos en su lugar
7. Ajusta la técnica al contexto - usa Planning Poker para historias a nivel de Sprint, Affinity Estimation para backlogs grandes, T-shirt sizing para roadmaps

Comienza con lo básico: consigue un mazo de cartas (físicas o digitales), establece 3-5 historias de referencia y ejecuta tu primera sesión. Cometerás errores - todos los equipos lo hacen. Pero después de unos pocos Sprints, te preguntarás cómo alguna vez estimaste sin él.

Continuar Leyendo

Preguntas Frecuentes

Preguntas Frecuentes (FAQs)