Estimando con puntos de historia en Scrum

Cuando se comienza con la adopción de agile en una organización o empresa, uno de los temas más polémicos lo constituye el cambio en la planificación y la estimación de las actividades y tareas. Tradicionalmente se ha estado estimando en tiempo, ya sean horas, jornadas laborales o meses. Al adoptar *agile *se utilizan otros métodos de estimación que de forma general tienden a crear confusión entre los integrantes de la organización. La gerencia y los patrocinadores de un proyecto, siempre querrán conocer la estimación de las actividades en tiempo y dinero.

Uno de los métodos o estrategias de estimación en el desarrollo ágil lo constituye la utilización de los Puntos de Historia (PH). Seguramente muchos han escuchado de este método, pero ¿qué son en realidad? ¿cómo se utilizan?

La definición de los PH puede ser relativa y controversial, pero para este artículo la estableceremos (y es más o menos un consenso) como una unidad de medida establecida para representar el “tamaño” de una determinada actividad. Cuando se habla de tamaño, se hace referencia a la combinación de varios factores, entre ellos: complejidad, esfuerzo, riesgos.

Ahora bien, ya se conoce que es un Punto de Historia, pero ¿cómo se utiliza? Me voy a referir a dos prácticas comunes:

• La primera y que yo recomiendo, hacer equivalente la historia de usuario que menor complejidad, esfuerzo y riesgo presente a un PH. De esta forma se está creando una unidad de medida que representa lo mismo para cada integrante del equipo. A partir de esta definición, la estimación del resto de las historias de usuario puede hacerse sobre la base del “tamaño” de la unidad.
• La segunda y que en mi criterio no otorga mayores beneficios, es hacer coincidir un PH con cierta cantidad de tiempo. He conocido casos donde se asigna como un PH el tiempo correspondiente a una jornada de trabajo. Definitivamente esto es muy relativo, pues una historia de usuario que tome a un desarrollador Senior dos jornadas, puede tomarle seis a un desarrollador Junior. En este sentido no recomiendo utilizar esta práctica.

Un concepto útil y muy relacionado con los PH es la Velocidad, pero sobre este estaré hablando en mi próximo post. También podremos revisar cómo entregar los valores de tiempo y costos a la gerencia y patrocinadores.

Algo muy importante y que todos debemos entender, es que los PH son definidos para un equipo, 1 PH del equipo A no tiene por qué tener el mismo “tamaño” (recordemos como tamaño la combinación de complejidad, esfuerzo, riesgos) que 1 PH del equipo B. Otro tema que debemos tener claro es que lo que se estima en PH es precisamente la historia de usuario y no las tareas en las que pueden descomponerse estas.

Sin dudas, la experiencia será quien forje en nuestro equipo la habilidad para estimar correctamente haciendo uso de los PH. Difícilmente la primera vez todo salga bien. Se cometerán errores y en la medida que seamos capaces de corregirlos, nos estaremos acercando más a la meta de convertirnos en una organización ágil.

Agradeceré cualquier comentario comentando su experiencia en el uso de los PH u otro método para la estimación en agile.