5. Escalas más comunes de Story Points

La elección de la escala de Story Points define cómo percibe el equipo las diferencias de esfuerzo entre historias. Una buena escala ofrece contraste suficiente entre trabajos pequeños y grandes, mantiene la conversación sencilla y facilita la planificación basada en velocidad. Las siguientes secciones repasan las escalas más empleadas y cómo adaptarlas a la realidad de cada equipo.

5.1. Serie de Fibonacci (1, 2, 3, 5, 8, 13)

La serie de Fibonacci es la escala más difundida en métodos como Planning Poker. Cada número resulta de sumar los dos anteriores, lo que genera una separación progresiva entre valores. Este crecimiento no lineal ayuda a que una historia de 8 puntos se perciba claramente más grande que una de 3, reduciendo discusiones sobre diferencias mínimas.

Ventajas principales:

  • Favorece conversaciones rápidas, ya que limita las opciones a un conjunto manejable.
  • Representa bien el incremento de incertidumbre a medida que las historias crecen.
  • Es compatible con múltiples herramientas digitales, lo que simplifica las sesiones remotas.

Para equipos que recién comienzan, la secuencia suele iniciarse en 1 y extenderse hasta 13 o 21 según la complejidad del producto.

5.2. Escala modificada o personalizada

Algunos equipos adaptan la escala para reflejar mejor su contexto. Pueden eliminar números para evitar discusiones innecesarias, añadir valores intermedios cuando notan saltos muy bruscos o incluso usar escalas híbridas que mezclan Fibonacci con múltiplos de dos.

Consideraciones al personalizar:

  • Reducir la ambigüedad: mantener pocos valores disponibles limita las diferencias de interpretación.
  • Respetar la progresión: aunque se modifique, la escala debe seguir creciendo de forma que el salto entre números represente incrementos reales de esfuerzo.
  • Documentar ejemplos: asociar historias típicas a cada valor evita que la escala pierda significado cuando se suma gente nueva al equipo.

La personalización es útil cuando la organización ya cuenta con datos históricos y quiere mantener coherencia al introducir nuevas disciplinas, como UX o QA automatizado.

5.3. Cómo elegir la escala adecuada para el equipo

No existe una escala universal. La elección depende del nivel de experiencia conjunta, del dominio del producto y de la necesidad de granularidad. Para elegir con criterio se recomienda:

  1. Evaluar el tamaño típico de las historias: si la mayoría cae en valores bajos, quizá baste una escala corta; si hay mucha variabilidad, conviene ampliar los extremos.
  2. Revisar datos de velocidad: la escala elegida debe permitir observar tendencias claras sprint a sprint.
  3. Probar y ajustar: después de unos pocos ciclos, realizar una retrospectiva específica para validar si las cifras reflejan el esfuerzo percibido.
  4. Buscar consenso: cualquier ajuste debe ser acordado por el equipo completo para preservar la credibilidad de las estimaciones.

El objetivo es contar con una escala que simplifique la conversación, no que la complique.

5.4. Ejemplos de aplicación práctica

Para ilustrar cómo se aplica la escala al día a día, se presenta un ejemplo hipotético de backlog y su clasificación en Story Points:

Historia Descripción Valor en Story Points Motivo del valor
HU-34 Actualizar textos en la página de ayuda. 1 Tarea de bajo riesgo y sin cambios técnicos.
HU-35 Agregar validaciones al formulario de registro. 3 Requiere pruebas y ajustes de interfaz, pero sin dependencias externas.
HU-41 Integrar el sistema con un servicio de pagos externo. 8 Incluye coordinar con proveedores, manejar errores y realizar pruebas end-to-end.
HU-50 Reescribir el módulo de reportes con un nuevo motor analítico. 13 Alta complejidad técnica, volumen considerable y riesgos de compatibilidad.

Este tipo de ejemplos se puede convertir en una guía interna para que el equipo recuerde cómo asignó valores en el pasado y mantenga consistencia cuando llegue trabajo similar.

Adoptar una escala clara y revisarla periódicamente garantiza que los Story Points sigan siendo un indicador útil para gestionar alcance, riesgos y compromisos con los stakeholders.