Scrum velocity team🌎 Actualizado mayo de 2026
La velocidad de un equipo Scrum (Scrum Velocity) mide cuántos Story Points completa un equipo en un Sprint. Un Story Point es una unidad relativa de esfuerzo que combina complejidad, volumen de trabajo e incertidumbre. La fórmula base es: Velocidad = Σ Story Points completados en el Sprint. Se usa para planificar releases, estimar fechas de entrega y detectar problemas de capacidad. Un equipo típico de 5-7 personas con Sprints de 2 semanas suele tener una velocidad estable de entre 20 y 60 Story Points por Sprint tras las primeras 3 iteraciones.
Cuándo usar esta calculadora
- Planificar cuántos Sprints faltan para completar un Product Backlog de 180 puntos con una velocidad promedio de 36 puntos/Sprint (→ 5 Sprints).
- Detectar una caída de rendimiento: el equipo pasó de 45 a 28 Story Points entre Sprint 4 y Sprint 6, señal de deuda técnica o conflictos de equipo.
- Estimar la fecha de lanzamiento de un MVP negociando el scope: si quedan 90 puntos y la velocidad es 30/Sprint, el release es en 3 Sprints (6 semanas con Sprints de 2 semanas).
- Comparar la capacidad real vs. comprometida: el equipo comprometió 50 puntos pero completó 38, evidenciando sobreestimación crónica que requiere recalibrar el Planning Poker.
Ejemplo de cálculo
- Ejemplo
- Resultado
Cómo funciona
4 min de lecturaCómo se calcula
La velocidad Scrum se calcula sumando los Story Points de todas las User Stories con estado Done (según la Definition of Done del equipo) al final de cada Sprint. Nunca se cuentan historias parcialmente terminadas.
Velocidad del Sprint N = Σ Story Points de historias COMPLETADAS en Sprint N
Velocidad Promedio = (V_Sprint1 + V_Sprint2 + ... + V_SprintN) / N
Sprints necesarios para completar el Backlog = Backlog Total (SP) / Velocidad Promedio
Fecha estimada de release = Fecha inicio + (Sprints necesarios × duración del Sprint en días)Ejemplo concreto:
---
Tabla de referencia
Benchmarks de velocidad según tamaño de equipo (Sprints de 2 semanas, roles completos: Dev + QA + PO):
| Tamaño del equipo | Velocidad baja | Velocidad típica | Velocidad alta | Observaciones |
|---|---|---|---|---|
| 3 personas | 10–15 SP | 18–25 SP | 28–35 SP | Equipo pequeño, poca coordinación |
| 5 personas | 20–30 SP | 35–50 SP | 55–70 SP | Tamaño óptimo según Scrum Guide |
| 7 personas | 30–45 SP | 50–70 SP | 75–90 SP | Límite recomendado por Scrum Guide |
| 9+ personas | Variable | Imprevisible | Imprevisible | Se recomienda dividir en 2 equipos |
| Equipo nuevo (Sprint 1-3) | 10–20 SP | — | — | Período de calibración, no usar para forecast |
> 📌 La Scrum Guide 2020 recomienda equipos de 3 a 9 personas (sin contar PO y Scrum Master) para mantener la agilidad y la comunicación efectiva.
---
Casos típicos
Caso 1 — Proyecto de e-commerce con equipo de 5 personas
Un equipo de desarrollo en Buenos Aires trabaja con Sprints de 2 semanas. Sus últimos 4 Sprints registraron: 42, 38, 45 y 41 SP.
Velocidad Promedio = (42 + 38 + 45 + 41) / 4 = 166 / 4 = 41,5 SP/Sprint
Backlog restante: 250 SP
Sprints necesarios: 250 / 41,5 ≈ 6,02 → 7 Sprints (redondeando con buffer)
Tiempo estimado: 7 × 2 semanas = 14 semanas (~3,5 meses)Caso 2 — Equipo con caída de velocidad (deuda técnica)
Sprint 1: 50 SP | Sprint 2: 48 SP | Sprint 3: 35 SP | Sprint 4: 29 SP
La caída del 42% entre el Sprint 2 y el Sprint 4 indica acumulación de deuda técnica o incorporación de un miembro nuevo. La velocidad promedio de 40,5 SP no es confiable para el forecast: conviene usar solo los últimos 2 Sprints (32 SP promedio) para estimar de forma conservadora.
Caso 3 — Release Planning con scope negociable
Backlog: 300 SP. Velocidad promedio estable: 50 SP/Sprint. Sprints de 2 semanas.
Sprints para todo el backlog: 300 / 50 = 6 Sprints = 12 semanas
Si el deadline es en 8 semanas (4 Sprints):
Scope posible: 4 × 50 = 200 SP → hay que recortar 100 SP del backlogEl Product Owner negocia qué 100 SP quedan fuera del MVP.
---
Errores comunes
1. Contar historias parcialmente terminadas: Si una historia de 8 SP está al 90% al finalizar el Sprint, el valor correcto a sumar es 0 SP. Contar puntos parciales infla artificialmente la velocidad y destruye la previsibilidad.
2. Comparar velocidades entre equipos distintos: Los Story Points son relativos a cada equipo. Un equipo que entrega 80 SP/Sprint no es el doble de productivo que uno de 40 SP/Sprint; simplemente tienen escalas de estimación diferentes. Este es uno de los errores más frecuentes en organizaciones con múltiples equipos Scrum.
3. Usar la velocidad del Sprint 1 o 2 para planificar: Los primeros 2-3 Sprints son de calibración. El equipo aún está aprendiendo a estimar en su propia escala. Usar esos datos para comprometer fechas al stakeholder lleva a promesas imposibles de cumplir.
4. No ajustar la capacidad por vacaciones, licencias o feriados: Si en el próximo Sprint hay 3 feriados nacionales y un miembro del equipo de vacaciones, la velocidad esperada debería reducirse proporcionalmente. Fórmula: Velocidad ajustada = Velocidad promedio × (Días disponibles / Días totales del Sprint).
5. Cambiar el tamaño del equipo sin resetear la velocidad histórica: Incorporar o perder un miembro invalida los datos históricos anteriores. Conviene reiniciar el promedio desde el primer Sprint con la nueva composición.
---
Calculadoras relacionadas
Preguntas frecuentes
¿Cuántos Sprints necesito para que la velocidad sea confiable?
La mayoría de los expertos y la literatura oficial de Scrum recomiendan al menos 3 Sprints completados antes de usar la velocidad para planificar releases. Con menos datos, la variabilidad es demasiado alta. Lo ideal es promediar entre 5 y 8 Sprints para tener un forecast robusto, especialmente si el equipo tuvo cambios de composición o de tecnología.
¿Qué pasa si el equipo no completó ninguna historia en un Sprint?
La velocidad de ese Sprint es 0 SP y debe incluirse en el promedio. Ignorarlo distorsiona la realidad. Un Sprint con 0 puntos es una señal de alerta grave: puede indicar historias mal refinadas, impedimentos no resueltos o un Sprint Goal demasiado ambicioso. El Scrum Master debe investigar la causa raíz en la Retrospectiva.
¿Hay una velocidad 'ideal' o 'normal' para un equipo Scrum?
No existe una velocidad universalmente ideal porque los Story Points son relativos a cada equipo. Sin embargo, como benchmark orientativo, un equipo de 5-7 personas con Sprints de 2 semanas suele ubicarse entre 30 y 60 SP/Sprint en estado estable. Lo importante no es el número absoluto sino su consistencia: una velocidad estable de 25 SP es más valiosa para planificar que una que oscila entre 10 y 60 SP.
¿Cómo se calcula cuántos Sprints faltan para terminar el proyecto?
La fórmula es: Sprints necesarios = Backlog restante (SP) / Velocidad promedio. Por ejemplo, si quedan 180 SP en el backlog y la velocidad promedio es 36 SP/Sprint, faltan exactamente 5 Sprints. Si los Sprints son de 2 semanas, eso equivale a 10 semanas calendario. Siempre agregá al menos un 10-15% de buffer para imprevistos.
¿La velocidad debe aumentar Sprint a Sprint? ¿Es un KPI de mejora?
No. La velocidad no es un KPI de performance ni de mejora. Usarla como objetivo genera comportamientos disfuncionales: los equipos inflan las estimaciones de Story Points para mostrar 'más velocidad'. La Scrum Guide 2020 y el Agile Manifesto enfatizan que la velocidad es una herramienta de planificación, no de evaluación del equipo. Lo que sí debería mejorar es la calidad del software y la satisfacción del cliente.
¿Qué es el 'capacity' y cómo se diferencia de la velocity?
La capacity (capacidad) es la cantidad de horas o días disponibles del equipo en un Sprint determinado, teniendo en cuenta vacaciones, feriados y licencias. La velocity es cuántos Story Points el equipo históricamente completa. Para planificar un Sprint, se ajusta la velocity esperada según la capacity disponible. Ejemplo: velocidad promedio 40 SP, pero el Sprint tiene solo el 70% de la capacity normal → velocidad esperada ajustada: 40 × 0,70 = 28 SP.
¿Se pueden usar Story Points en equipos que trabajan con Kanban o metodologías híbridas?
Sí, aunque en Kanban puro se prefiere medir el Cycle Time (tiempo promedio que tarda una tarea en completarse) en lugar de Story Points, ya que no hay Sprints fijos. En metodologías híbridas (Scrumban), es válido usar Story Points si el equipo tiene iteraciones. En cualquier caso, lo más importante es que el equipo use consistentemente la misma unidad de medida y no cambie la escala sin recalibrar el historial.
¿Cómo afectan los feriados nacionales argentinos a la velocidad del Sprint?
Cada feriado nacional (Argentina tiene aproximadamente 19 feriados inamovibles y trasladables por año según el calendario del Ministerio de Trabajo) reduce la capacity del Sprint. En un equipo de 5 personas con Sprints de 10 días hábiles, un feriado representa el 2% de la capacity total. Para ajustar: Velocidad ajustada = V_promedio × (días hábiles disponibles / días hábiles totales del Sprint). El Scrum Master debería planificar estos ajustes al inicio del Sprint Planning.
Fuentes y referencias
Metodología y confianza
Contenido revisado por el equipo editorial de Hacé Cuentas, con apego a nuestra política editorial y metodología de cálculo.
Última revisión: 22 de mayo de 2026. Los parámetros fiscales, legales y datos se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos. Leé nuestra política de privacidad.
Resultados orientativos. Para decisiones financieras, médicas o legales críticas, consultá con un profesional.