¿Sientes que tu planificación de Sprint es más una carta a los Reyes Magos que un compromiso real? Si estás cansado de ver cómo las tareas se arrastran de un Sprint a otro como zombis, este artículo es para ti.
Antes de profundizar, te dejo aquí mi vídeo de formación completa (Capítulo 25 de mi curso de Scrum), donde aterrizamos toda esta teoría con ejemplos reales del sector retail y moda. Te recomiendo verlo mientras lees esta guía.
[INSERTAR VÍDEO DE YOUTUBE AQUÍ]
El Gran Engaño de las Horas: Por qué 1h ≠ 1h
Muchos Managers y Product Owners cometen el error fatal de pedir estimaciones en horas. Parece lógico, ¿verdad? El problema es que el tiempo es subjetivo.
Imagina que tenemos que integrar una pasarela de pago en nuestra tienda de moda online:
- Sara (Junior): Estima 12 horas porque nunca lo ha hecho.
- Miguel (Mid): Estima 6 horas porque ya conoce el código.
- Elena (Senior): Estima 3 horas porque ella misma escribió esa API.
¿Quién tiene razón? Todos. Por eso, estimar en horas es una trampa que solo genera presión, frustración y fechas de entrega que nunca se cumplen. En Scrum, no medimos el tiempo que pasas sentado, medimos el tamaño del esfuerzo necesario.
La Anatomía del Story Point: El Triángulo del Éxito
Para que un equipo de alto rendimiento (donde conviven diseñadores, expertos en Paid Media y desarrolladores) hable el mismo idioma, necesitamos descomponer el trabajo en tres factores fundamentales. Olvida los tecnicismos; hablemos de realidades:
A. Complejidad (El reto mental)
No es lo mismo subir un banner (algo mecánico) que configurar un sistema de lógica de descuentos cruzados que depende de mil variables. La complejidad mide cuántas “neuronas” tenemos que quemar. ¿Es un camino asfaltado o una montaña llena de baches?
B. Esfuerzo / Volumen (La cantidad de manos)
Puedes saber perfectamente cómo hacer una tarea (baja complejidad), pero si tienes que replicar ese diseño para 50 formatos de redes sociales, el volumen es alto. El esfuerzo mide cuántas “kilómetros” tenemos que recorrer.
C. Incertidumbre / Riesgo (La niebla)
Este es el factor que más se olvida. ¿Dependemos de un proveedor externo? ¿La documentación de la herramienta es mala? ¿Es una tecnología que no hemos probado? Si hay niebla en la carretera, no puedes ir a 120 km/h. La incertidumbre “engorda” el Story Point para proteger al equipo de lo desconocido.
Fibonacci: Por qué no usamos números “normales”
En mi curso verás que usamos la secuencia de Fibonacci (1, 2, 3, 5, 8, 13, 21…). ¿Por qué? Porque cuanto más grande es el reto, más difícil es ser precisos.
No tiene sentido discutir si una tarea es un 10 o un 11. Esa diferencia es ruido. Pero sí hay una diferencia clara entre un 8 y un 13. El salto de números nos obliga a ser honestos: si no cabe en un 8, salta al 13, y si es un 13, probablemente esa Historia de Usuario sea una “Monster Story” que necesita ser dividida.
El Sistema de Calibración: Cómo crear tu Escala y elegir la “Tarea Ancla”
Uno de los mayores errores de los equipos que empiezan con Scrum es intentar estimar en el vacío. Si te pregunto cuánto pesa una piedra sin dejarte tocarla ni verla, fallarás. Para estimar bien, el equipo necesita un punto de referencia común. En agilidad, esto lo llamamos la Tarea Ancla.
¿Qué es la Tarea Ancla?
El ancla es una Historia de Usuario que el equipo ya ha realizado en el pasado, que todos conocen perfectamente y en la que todos están de acuerdo sobre su tamaño. Es nuestro “metro” particular.
Para un equipo de Ecommerce de moda, un ancla de 3 Story Points podría ser: “Subir una nueva categoría de producto con su banner, metadatos y filtros básicos”.
A partir de aquí, ya no estimamos “desde cero”, sino por comparación relativa:
- ¿Esta nueva tarea es el doble de difícil que nuestra ancla? Entonces es un 5 o un 8.
- ¿Es mucho más sencilla? Entonces es un 1 o un 2.
Pasos para crear tu Escala de Estimación de Equipo
Para que este sistema funcione en tu próximo Planning, sigue estos pasos que explico en el vídeo del curso:
- Selecciona el “Pequeño Conocido”: Buscad una tarea que sea simple, sin riesgo y que no lleve mucho tiempo. Ese será vuestro 1 o Suele ser algo mecánico, como cambiar un texto legal en el footer.
- Define el “Ancla Central” (El 3 o 5): Es la tarea que representa el “pan de cada día” del equipo. Ni muy simple, ni una odisea técnica. Tener este ancla en el centro de la escala de Fibonacci ayuda a que el equipo no tienda siempre a puntuar por lo alto.
- Crea una Matriz de Referencia: No la guardes en un cajón. Ten una tabla visible (o un documento compartido) donde pongas ejemplos reales:
- 2 SP: Ajustes menores de CSS o cambio de creatividades en campañas de Paid.
- 5 SP (Ancla): Creación de Landing Page para nueva colección (Diseño + Maquetación).
- 13 SP: Integración de un nuevo método de pago (Alta complejidad + Alta incertidumbre).
El Peligro de las Anclas “Flotantes”
Cuidado: el ancla debe ser estable. Si el equipo mejora y se vuelve más rápido, el valor del Story Point no debe cambiar. Lo que cambiará será vuestra Velocidad (terminaréis más puntos en el mismo tiempo), pero el ancla sigue siendo la misma.
Si empiezas a decir que lo que antes era un 5 ahora es un 3 porque “ya somos muy rápidos”, estarás destruyendo tus métricas históricas y perderás la capacidad de predecir el futuro con los Stakeholders.
Consejo pro para el PO: En el Refinamiento Operativo, ten siempre a mano tu lista de “Tareas Ancla”. Cuando el equipo dude entre un 5 o un 8, recuérdales: “¿Esto es más o menos complejo que la Landing de la temporada pasada que puntuamos como un 5?”. Esa sola pregunta ahorra 15 minutos de debate inútil.
El Escudo del Product Owner: La Velocidad
Como Product Owner en el sector moda, te enfrentarás a Stakeholders que quieren el lanzamiento de temporada “para ayer”. Aquí es donde los Story Points se convierten en tu mejor aliado.
La Velocidad es la suma de puntos que tu equipo termina de media por Sprint.
- Si tu equipo tiene una velocidad media de 30 SP.
- Y tu Backlog para la nueva colección suma 90 SP.
- Realidad: Necesitas 3 Sprints. Punto.
No es una opinión, son datos. Esto te permite negociar desde la autoridad: “Querido Stakeholder, con nuestra capacidad actual no podemos meter esta campaña extra. O sacamos algo del mismo tamaño del Sprint, o aceptamos que la entrega se retrasa”.
Caso Práctico: Estimando un Ecommerce de Moda
En el vídeo que encabeza este artículo, desglosamos cómo un equipo multidisciplinar estima de forma relativa.
No comparamos una tarea con el reloj, la comparamos con una “Tarea Ancla”. Si todos estamos de acuerdo en que “Crear una ficha de producto básica” es un 3, entonces “Crear un Lookbook interactivo” claramente es un 8 o un 13.
Esta técnica permite que el de Paid Media entienda el esfuerzo del Dev, y que el Diseñador entienda la complejidad de la integración técnica. Se acaba el “yo pensaba que esto era un momento”.
El Cambio de Mentalidad
Pasar de horas a Story Points no es solo un cambio de unidad de medida; es un cambio de cultura. Es pasar del control a la confianza, de la adivinación a la estadística.
Si quieres que tu equipo deje de estar quemado y empiece a entregar valor real de forma constante, empieza hoy mismo a aplicar estos tres factores: Complejidad, Esfuerzo e Incertidumbre.
¿Quieres llevar a tu equipo al siguiente nivel?
Llevo años ayudando a empresas a implementar Scrum de forma práctica, sin teorías vacías, bajando al barro del día a día. Si quieres que analice tu caso particular o el de tu equipo:
👉 https://mrtorras.es/scrum/
No olvides suscribirte a mi canal de YouTube Carlos Torras para seguir este curso gratuito y convertirte en un experto en Agilidad.
