Story points: cómo medir el trabajo sin adivinar horas
Los story points indican cuán grande es un trabajo frente a otros, no cuánto tarda. De dónde vienen, cómo usarlos y cuándo es mejor contar historias.
Los story points son un número que un equipo asigna a un trabajo para indicar cuán grande es comparado con otros trabajos. No miden horas. Un 5 es más grande que un 3 y más pequeño que un 8, y lo que significa un 5 lo decide el equipo que lo usa.
De dónde vienen
Los story points vienen de Extreme Programming. En Story Points Revisited, Ron Jeffries, uno de los primeros practicantes del método, describe cómo fue. Los equipos de XP estimaban primero las historias en tiempo. Luego usaron “días ideales”, el tiempo que necesitaría una pareja sin interrupciones, y lo multiplicaban por un factor de carga de unas tres veces para obtener el tiempo real. A los interesados les resultaban confusos los recuentos de días, así que los equipos empezaron a llamarlos “puntos”. Jeffries dice que quizá inventó el término y, si fue así, ahora lo lamenta. El libro Agile Estimating and Planning de Mike Cohn (2005) ayudó a extender la práctica.
Scrum no exige los story points. La Scrum Guide no los menciona. Dice que los Developers que harán el trabajo son los responsables de dimensionarlo, y deja el método en sus manos.
Por qué los usa la gente
Hay poca investigación sólida detrás de los story points. Las razones que dan los equipos son prácticas.
Comparar es más fácil que predecir. Es difícil decir “esto lleva dos días”. Es más fácil decir “esto es más o menos el doble que aquello”. Una escala relativa permite acordar sin discutir sobre horas.
La conversión sale de tu propio historial. Las personas son optimistas con su propio tiempo. En un estudio de 1994 de Roger Buehler, Dale Griffin y Michael Ross, estudiantes predijeron que sus tesis de fin de carrera tardarían 33,9 días de media, y tardaron 55,5 (Journal of Personality and Social Psychology). Los puntos evitan una promesa en horas. Sumas los puntos que tu equipo terminó realmente en los sprints recientes, y ese total, llamado velocidad, indica cuánto coger la próxima vez.
Cubren el trabajo de todo el equipo y la duda. Una escala de puntos incluye las pruebas, la revisión y lo desconocido. Cuanto mayor es el número, menos seguro es.
Jeffries mismo deplora ahora su mal uso y prefiere cortar las historias hasta que cada una sea pequeña. Es una alternativa razonable, y vuelve más abajo.
Cómo usarlos
- Elige una historia de referencia. Escoge una historia terminada, acuerda que es un 2 o un 3, y compara las demás con ella.
- Dimensiona el trabajo completo. Incluye diseño, construcción, pruebas y revisión. Más trabajo, más complejidad e incertidumbre empujan el número hacia arriba.
- Usa una escala limitada. Los números al estilo Fibonacci (1, 2, 3, 5, 8, 13) obligan a elegir entre “más grande” y “más pequeño” y evitan discusiones sobre 6 o 7.
- Fija un techo. Una historia por encima de 13 es demasiado grande para planificarla. Divídela.
- Cuenta solo las historias terminadas. Al final del sprint, suma los puntos de las historias que están hechas. Una historia casi terminada no suma nada todavía.
- Planifica con el promedio. Toma la media de tus últimos sprints y úsala como velocidad.
Así podría verlo un equipo. “Añadir una casilla de recordarme” es un 2. “Restablecer una contraseña por correo” es un 5, con correo, caducidad y pruebas. “Exportar informes a PDF con maquetación” es un 13 y probablemente hay que dividirla. Si los tres últimos sprints terminaron 18, 22 y 20 puntos, el equipo planifica unos 20.
Usa planning poker para acordar los números juntos.
Errores que conviene evitar
- Convertir puntos en horas. “Un punto es medio día” convierte una escala relativa en un mal reloj.
- Comparar la velocidad de equipos distintos. Los puntos de cada equipo significan algo distinto. Un número mayor no quiere decir que se haya hecho más.
- Juzgar a las personas por la velocidad. Cuando los puntos se convierten en un objetivo, la gente sobredimensiona para alcanzarlo.
- Dar crédito parcial. Cuenta una historia cuando esté terminada, y no antes.
- Reestimar después. Cambiar los números cuando el trabajo ya está terminado oculta lo que has aprendido.
- Dejar que cada persona use su propia escala. El valor del número es que el equipo lo comparte.
Cuándo no es la herramienta adecuada
- Cuando tus elementos tienen más o menos el mismo tamaño. Cuenta los elementos. Jeffries prefiere cortar las historias en pequeño a dimensionarlas.
- Para tareas personales. Si necesitas una duración, usa minutos.
- Cuando un cliente paga por hora. Quiere horas, así que estima horas.
- Cuando los puntos no aportan nada. Jeffries dice que los abandones si no ayudan, y que los conserves si al equipo le gustan.
- Para un equipo recién creado. Sin sprints previos no hay velocidad. Termina unos cuantos sprints y observa lo que completas.
En Prior
Elige Ágil · Scrum o Ágil · Scrumban en Tipo de proyecto al crear o editar un proyecto. Las tareas de ese proyecto se dimensionan entonces en puntos en lugar de por prioridad.
- Asigna los puntos. Los detalles de la tarea tienen una fila Puntos de historia, con una fila de cartas: 0, ½, 1, 2, 3, 5, 8, 13 y 21, más Quitar. El redactor de tareas tiene una píldora Puntos con el mismo mazo. Un valor fuera del mazo, como 4, obtiene su propia carta. Los puntos van de 0 a 999 en pasos de 0,5. La pista lo dice: “El tamaño del trabajo, no el tiempo que lleva.”
- Mira el tamaño. Un distintivo de puntos sustituye al glifo P1 a P4 en tarjetas y filas: tres barras, con una iluminada hasta 1 punto, dos hasta 3 y tres hasta 13. Por encima de 13, el distintivo muestra una “!” coral, porque la historia debería dividirse. Una tarea sin estimación muestra las barras vacías y dice Sin estimar. La prioridad sigue siendo editable.
- Estima juntos. La pestaña Planning Poker escribe el valor acordado en la tarea. Mira la guía de planning poker.
- Divide lo que es demasiado grande. La mesa de poker ofrece Dividir la tarea, y Prior AI propone las piezas si tu cuenta tiene Pro. Mira Dividir una historia.

En un proyecto Scrum, los ciclos pasan a ser Sprints. Cada tarjeta de sprint muestra el progreso, como “13 de 21 pts hechos”, y cuántas tareas están “sin estimar”, y el editor de sprint muestra los puntos que te has comprometido a hacer. El resumen de Velocidad encima de las tarjetas es el promedio de los puntos hechos en los últimos tres sprints terminados, redondeado a un decimal. Hasta que un sprint termine, dice “Termina un sprint para ver tu velocidad”.
Los puntos se conservan cuando vuelves a Kanban o Estándar. Se ocultan, no se borran. También viajan con la sincronización, la exportación de datos y las herramientas MCP, y una estimación numérica de Linear se convierte en story points al importar. Para la referencia completa, mira Story points y Ciclos y sprints.