Story Points vs Effort Points: Guía de Estimación

Story points y effort points miden la complejidad del trabajo, pero abordan la estimación de manera diferente. GitScrum usa effort points con una escala simplificada (XS a XL) que incluye guías de horas, haciendo la estimación más accesible para los equipos mientras mantiene los beneficios del dimensionamiento relativo de los story points.

Resumen Comparativo

Entendiendo Story Points

STORY POINTS TRADICIONALES
══════════════════════════

CONCEPTO:
─────────────────────────────────────
Los story points miden complejidad RELATIVA
No horas, no días - comparación pura

"¿Qué tan compleja es la Tarea B vs Tarea A?"
Si Tarea A = 3 puntos y Tarea B es el doble
Entonces Tarea B = 5 u 8 puntos

ESCALA FIBONACCI:
─────────────────────────────────────
1  - Trivial (línea base de referencia)
2  - Simple
3  - Pequeño
5  - Mediano
8  - Grande
13 - Muy grande
21 - Épica (debe dividirse)

¿POR QUÉ FIBONACCI?
─────────────────────────────────────
├── La incertidumbre crece con el tamaño
├── Difícil distinguir 14 vs 15
├── Los gaps fuerzan elecciones significativas
└── Refleja límites naturales de estimación

EJEMPLO:
─────────────────────────────────────
Tarea de referencia: "Agregar validación a form" = 3 pts

Comparando nuevas tareas:
├── "Cambiar color de botón" → menor → 1 pt
├── "Agregar date picker" → similar → 3 pts
├── "Construir dashboard usuario" → mucho mayor → 13 pts
└── "Implementar sistema auth" → épica → 21 pts (¡dividir!)

Entendiendo Effort Points

EFFORT POINTS DE GITSCRUM
═════════════════════════

CONCEPTO:
─────────────────────────────────────
Los effort points combinan dimensionamiento
relativo con guías opcionales de horas

Mismos beneficios de comparación relativa
Más referencias prácticas de tiempo

ESCALA DE TALLAS CON HORAS:
─────────────────────────────────────
┌────────┬─────────┬─────────────────────┐
│ Talla  │ Puntos  │ Duración Típica     │
├────────┼─────────┼─────────────────────┤
│ XS     │ 1       │ Menos de 2 horas    │
│ S      │ 2       │ 2-4 horas           │
│ M      │ 3       │ 4-8 horas (1 día)   │
│ L      │ 5       │ 1-2 días            │
│ XL     │ 8       │ 2-5 días            │
└────────┴─────────┴─────────────────────┘

POR QUÉ FUNCIONA:
─────────────────────────────────────
├── Simple de entender
├── Solo 5 opciones para elegir
├── Guías de horas reducen debates
├── Aún permite seguimiento de velocidad
└── Funciona para equipos nuevos y expertos

EJEMPLO:
─────────────────────────────────────
Tarea: "Agregar edición de perfil de usuario"

Desglosándola:
├── ¿Arreglo rápido? ¿Menos de 2 hrs? → XS (1 pt)
├── ¿Trabajo de medio día? → S (2 pts)
├── ¿Esfuerzo de día completo? → M (3 pts)
├── ¿Un par de días? → L (5 pts)
└── ¿Semana de trabajo? → XL (8 pts)

Consenso del equipo: "Unos 2 días" → L (5 pts)

Cuándo Usar Cada Uno

ELIGIENDO TU ENFOQUE
════════════════════

USA EFFORT POINTS CUANDO:
─────────────────────────────────────
✓ Equipo nuevo en estimación ágil
✓ Stakeholders preguntan "¿cuánto tiempo?"
✓ Necesitas referencias concretas de planificación
✓ Niveles de experiencia mixtos en el equipo
✓ Más simple es mejor para tu contexto
✓ Convirtiendo desde estimaciones en horas

USA STORY POINTS CUANDO:
─────────────────────────────────────
✓ Equipo tiene práctica madura de estimación
✓ Complejidad abstracta funciona bien
✓ Necesitas granularidad Fibonacci
✓ Equipo resiste asociaciones de tiempo
✓ Gran varianza en velocidades individuales
✓ Ya tienes velocidad establecida

ENFOQUE HÍBRIDO:
─────────────────────────────────────
Los effort points de GitScrum soportan ambos:
├── Usa tallas (visual)
├── Rastrea valores de puntos (numérico)
├── Referencia horas (opcional)
└── Calcula velocidad (igual que story points)

Técnicas de Estimación

CÓMO ESTIMAR
════════════

PLANNING POKER:
─────────────────────────────────────
1. Presenta la tarea/story
2. Discute requisitos
3. Todos eligen talla simultáneamente
4. Revelar elecciones
5. Discutir outliers
6. Re-votar si es necesario
7. Consenso o promedio

Ejemplo de sesión:
┌─────────────────────────────────────┐
│ Tarea: "Implementar reset password" │
├─────────────────────────────────────┤
│ Voto 1:                             │
│ Dev A: M    Dev B: L    Dev C: M    │
│                                     │
│ Discusión: "¿Y el email?"           │
│ Dev B: "Olvidé el template"         │
│                                     │
│ Voto 2:                             │
│ Dev A: M    Dev B: M    Dev C: M    │
│                                     │
│ Consenso: M (3 puntos)              │
└─────────────────────────────────────┘

TALLAS DE CAMISETA:
─────────────────────────────────────
Método rápido de dimensionamiento:

1. Ordenar tareas por complejidad
2. Asignar tallas
3. Convertir a puntos

┌────────────────────────────────────────┐
│ XS │ S │ M │ L │ XL │                  │
├────┼───┼───┼───┼────┤                  │
│ T1 │T2 │T4 │T6 │ T8 │ ← Tareas ordena. │
│    │T3 │T5 │T7 │    │                  │
│    │   │   │   │    │                  │
└────┴───┴───┴───┴────┘

COMPARACIÓN DE REFERENCIA:
─────────────────────────────────────
1. Establecer tareas de referencia por talla
2. Comparar nuevas tareas con referencias
3. Emparejar con referencia más cercana

Biblioteca de referencias:
├── XS: "Actualizar valor de config"
├── S:  "Agregar validación de form"
├── M:  "Crear nuevo endpoint API"
├── L:  "Construir widget de dashboard"
└── XL: "Implementar integración"

Planificación de Sprint con Puntos

PLANIFICACIÓN DE CAPACIDAD
══════════════════════════

CALCULANDO CAPACIDAD:
─────────────────────────────────────
Equipo: 4 desarrolladores
Sprint: 2 semanas (10 días laborables)
Velocidad histórica: 35-40 pts/sprint

Capacidad disponible:
├── Considerar PTO, reuniones
├── Incluir buffer para imprevistos
└── No sobrecomprometerse

Ejemplo:
┌─────────────────────────────────────┐
│ CAPACIDAD DEL SPRINT                │
├─────────────────────────────────────┤
│ Velocidad histórica: 38 pts avg     │
│ Este sprint:                        │
│ ├── Dev A: Completo (10 días)       │
│ ├── Dev B: Completo (10 días)       │
│ ├── Dev C: 8 días (2 PTO)           │
│ └── Dev D: Completo (10 días)       │
│                                     │
│ Capacidad ajustada: 38 × 0.9 = 34 pt│
│ Buffer (10%): 3 pts                 │
│ Compromiso seguro: 31 pts           │
└─────────────────────────────────────┘

BACKLOG DEL SPRINT:
─────────────────────────────────────
┌─────────────────────────────────────┐
│ Story/Tarea            │ Effort    │
├────────────────────────┼───────────┤
│ Edición perfil usuario │ L (5 pts) │
│ Flujo reset password   │ M (3 pts) │
│ Widgets dashboard      │ L (5 pts) │
│ API rate limiting      │ M (3 pts) │
│ Bug: Login timeout     │ S (2 pts) │
│ Notificaciones email   │ L (5 pts) │
│ Página de settings     │ M (3 pts) │
│ Actualizar docs        │ S (2 pts) │
├────────────────────────┼───────────┤
│ TOTAL COMPROMETIDO     │ 28 pts    │
│ Buffer restante        │ 3 pts     │
└────────────────────────┴───────────┘

Seguimiento de Velocidad

MIDIENDO VELOCIDAD
══════════════════

¿QUÉ ES VELOCIDAD?
─────────────────────────────────────
Puntos completados por sprint
Promedio en el tiempo = capacidad predecible

Sprint    │ Comprometido│ Completado
──────────┼─────────────┼──────────
Sprint 1  │ 35 pts      │ 32 pts
Sprint 2  │ 35 pts      │ 36 pts
Sprint 3  │ 38 pts      │ 35 pts
Sprint 4  │ 35 pts      │ 38 pts
Sprint 5  │ 38 pts      │ 37 pts
──────────┼─────────────┼──────────
Promedio  │             │ 35.6 pts

GRÁFICO DE VELOCIDAD:
─────────────────────────────────────
Puntos│
   40 │      ■         ■
      │  ■       ■         ■
   35 │──────────────────────  Promedio
      │
   30 │  ■
      │
   25 ├──────────────────────────
      S1  S2  S3  S4  S5  S6

USANDO VELOCIDAD:
─────────────────────────────────────
├── Planificar futuros sprints
├── Proyectar fechas de completitud
├── Identificar cambios de capacidad
├── Detectar deriva en estimaciones
└── Comunicar con stakeholders

Ejemplo de proyección:
Trabajo restante: 180 puntos
Velocidad: 36 pts/sprint
Sprints estimados: 5 (10 semanas)

Errores Comunes

ANTI-PATRONES DE ESTIMACIÓN
═══════════════════════════

ERROR 1: CONVERTIR A HORAS
─────────────────────────────────────
❌ "1 punto = 4 horas"
❌ "¿Cuántas horas es un L?"
❌ Tratar puntos como unidades de tiempo

✓ Puntos miden complejidad, no tiempo
✓ Guías de horas son referencias, no reglas
✓ Velocidad normaliza con el tiempo

ERROR 2: ESTIMACIONES INDIVIDUALES
─────────────────────────────────────
❌ "Esto es 5 puntos para mí"
❌ Ajustar por velocidad individual
❌ Escalas diferentes por persona

✓ Estimaciones de equipo (consenso)
✓ Escala única para todos
✓ Velocidad considera mezcla del equipo

ERROR 3: NUNCA RECALIBRAR
─────────────────────────────────────
❌ Mismas referencias para siempre
❌ Ignorar deriva de estimaciones
❌ No revisar reales vs estimados

✓ Revisar tareas de referencia trimestralmente
✓ Comparar estimados con reales
✓ Ajustar cuando el equipo cambia

ERROR 4: SOBRE-PRECISIÓN
─────────────────────────────────────
❌ "Esto es exactamente 4.5 puntos"
❌ Debatir XS vs S por 20 minutos
❌ Parálisis por análisis

✓ Aceptar incertidumbre de estimación
✓ Redondear a talla más cercana
✓ Timeboxear discusiones (2 min/item)

Mejores Prácticas

1. Estimar como equipo - consenso construye entendimiento compartido
2. Usar tareas de referencia - comparar, no calcular
3. Rastrear velocidad - patrones emergen después de 5+ sprints
4. Incluir todo - testing, revisión, documentación
5. Dividir items grandes - nada mayor a XL/8 puntos
6. Timeboxear estimación - 2 minutos por item máximo
7. Revisar regularmente - retro sobre precisión de estimación
8. Confiar en el proceso - velocidad normaliza varianza

Configuración en GitScrum

CONFIGURANDO EFFORT POINTS
══════════════════════════

ESTIMACIÓN DE TAREAS:
─────────────────────────────────────
Al crear/editar una tarea:
1. Abrir detalles de la tarea
2. Encontrar campo Effort
3. Seleccionar talla: XS, S, M, L, XL
4. Puntos calculados automáticamente

VISTA DE PLANIFICACIÓN DE SPRINT:
─────────────────────────────────────
El backlog del sprint muestra:
├── Total de puntos comprometidos
├── Umbral de capacidad
├── Efforts de tareas individuales
└── Seguimiento de progreso

REPORTES DE VELOCIDAD:
─────────────────────────────────────
Workspace → Reports → Sprint KPIs
├── Puntos por sprint
├── Tasas de completitud
├── Progresión del burndown
└── Análisis de tendencias

Soluciones Relacionadas

• Planificación y Ejecución de Sprint
• Técnicas de Estimación Ágil
• Guía de Seguimiento de Velocidad
• Deuda Técnica con Effort Points