Tradicionalmente los proyectos de software son estimados usando períodos de tiempo como unidad de medida. "Esta funcionalidad llevará 5 días para ser completada" o "Esta tarea me tomará 2 horas." Los procesos ágiles en general han adoptado otra forma de estimación de actividades y alguna confusión se ha creado en torno a esta cuestión.

Una de las estrategias más populares es el uso de Puntos de Historia como unidad de medida de las actividades. Pero, ¿qué son de hecho los Puntos de Historia? La respuesta clásica es "una unidad de medida creada para expresar el tamaño global de una actividad," Tenga en cuenta que usamos la palabra TAMAÑO, un error común es tratar sólo los a los puntos de historia como una medida de complejidad, cuando en realidad los puntos de historia son una combinación de cosas como:

• Complejidad: por ejemplo, "Esta regla de negocio tiene muchos escenarios posibles"
• Esfuerzo: por ejemplo, "Esta modificación es simple, pero hay que hacerla en muchas pantallas"
• Riesgos: por ejemplo, "Tenemos que usar un framework X, pero nadie en el equipo tiene experiencia" 
• Etc.

Otro aspecto importante es que los puntos de historia, a diferencia de las estimaciones de tiempo, son relativas. Una forma común de trabajar es elegir un tema que parece ser pequeño y dar un valor de referencia, a partir de allí las otras funcionalidades se estiman en relación a la referencia. Pero para entender realmente cómo funcionan los puntos de historiaes necesario pensar también en el concepto de velocidad o Veloctiy, que no es más que el número de puntos de historia que un equipo consigue entregar en una iteración, con estas dos herramientas es posible crear una planificación de releases con mucha más calidad.