search
top

¿Por qué utilizamos Puntos Historia para estimar y no horas?

Hace unos días te dejamos en un post La experiencia de un año automatizando estimaciones con Puntos Historia en 233 Grados de TI y hoy queremos ampliar esa experiencia con una pregunta que se repite con demasiada frecuencia: por qué usar Puntos Historia y no horas directamente.

El tema de la estimación ágil ya lo hemos tratado en varias ocasiones. Los Puntos Historia os recordamos que son un número que indica la complejidad relativa de una tarea o necesidad frente a otra. Se utilizan para establecer el “tamaño” de una historia de usuario en función de complejidad – riesgo. Podéis leer más en el libro “Cómo sobrevivir… A la planificación de un proyecto ágil” de 233 Grados de TI o en varios post del blog, como ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes o Puntos historia vs Puntos Función o Cómo estimamos proyectos Scrum o en general ágiles .

El tiempo que se tardará frente al tamaño de la tarea

Una analogía para estos casos (podéis leer más aquí, el ejemplo es del blog de Crisp) es comparar los Puntos Historia con la duración temporal (de una tarea) utilizando el símil del viaje con niños en el coche,  en el que nos suelen preguntar: ¿Cuánto falta para llegar?

Y, realmente, con exactitud, no sabes que responder. El caso es que tú sabes la distancia, pero no puedes predecir si habrá retenciones o paradas inesperadas, asi que te limitas a contestar “Si no pasa nada, estaremos allí en, más o menos, X horas”. La distancia entre dos ciudades puede ser la misma, pero el tiempo que se tarda en ir de una a otra puede variar.

Trasladándonos a un proyecto ágil, la distancia serían los Puntos Historia, los kilómetros que más o menos sabemos que hay de aquí a la ciudad a la que vamos. La distancia siempre va a ser la misma, es decir, es constante, pero las horas varían del momento de día en el que salga, y sus atascos, las fechas, etc.

Mayor consenso entre las personas del equipo

Si nos paramos a pensar, no todos trabajamos a la misma velocidad. Mike Cohn en un artículo (puedes leerlo aquí) para explicar esto también vuelve comparar la acción de realizar una historia de usuario frente a recorrer un camino en cierto tiempo.

Nos dice que no todas las personas coincidirán en el tiempo que creen que necesitarán para recorrer cierta distancia (tiempo de realización), y por lo tanto nunca llegarán a un acuerdo a la hora de recorrerlo a la vez. Bien, pues a la hora de estimar las historias de usuario en horas, sucede lo mismo, cada persona conoce tanto sus habilidades como limitaciones y por lo tanto dos personas no tienen por qué coincidir en el tiempo que crean necesario para realizar la misma historia de usuario.

Entonces podemos decir que los Puntos Historia son una unidad más abstracta, que nos permiten llegar a un acuerdo entre las personas del equipo, las cuales tenemos diferentes habilidades y diferentes ritmos a la hora de trabajar. Para llegar a este consenso se suele utilizar la técnica Planning Poker, que también fortalece las relaciones entre las personas, puedes leer más de esta técnica en el libro Gestión de proyectos ágil… y las experiencias de más de 12 años de proyectos ágiles de 233 Grados de TI.

Menor tiempo de estimación

En un artículo (que podéis leer aquí) escrito por Jeff Sutherland (uno de los padres de Scrum) afirma, a partir de un caso de estudio con cinco empresas, que utilizar Puntos Historia reduce el tiempo que le dedicamos a estimar un 80%.

Este punto también se relaciona con el anterior, ya que si el consenso entre las personas del equipo a la hora de estimar se consigue antes, el tiempo que dedicamos a estimar en las reuniones de planificación será menor.

Por otro lado, cuando estimamos en Puntos Historia normalmente se suele usar una escala o rango (puedes leer más en el post del blog elige una buena escala de Puntos Historia y te ahorrarás problemas) como es el Fibonacci (nosotros lo usamos), esta escala no es continua y tiene menos valores que si usásemos el tiempo o un rango de 1 a 100 con los 100 valores, es por ello que es más rápido estimar, al haber menos valores a elegir se evitan discusiones y debates eternos.

Menor estrés en el equipo

El equipo no esta tan presionado, al utilizar Puntos Historia las personas no tienen tanto miedo a equivocarse, es decir, miedo de no terminar a tiempo la historia de usuario en el tiempo que se dijo. El estrés que siente el equipo es menor porque ahora no tienen que trabajar pendientes del reloj sino del esfuerzo.

Concluyendo…

Hemos querido compartir con vosotros los motivos por los que es mejor estimar en Puntos Historia nuestros proyectos Scrum. Pero esto es como todo, lo correcto para nuestro equipo puede que no lo sea para el tuyo.

Se trata de una buena práctica a la que cuesta adaptarse los primeros meses ya que no tenemos experiencia ni velocidad media en la que basarnos, pero os tenemos que decir que a nosotros nos ha ayudado mucho, ya no iniciamos un sprint sin alguna historia de usuario sin estimar.

5 Respuestas to “¿Por qué utilizamos Puntos Historia para estimar y no horas?”

  1. Andreu Gª dice:

    Entiendo los puntos historia como una forma de evitar el frecuente malentendido entre horas transcurridas y horas trabajadas (o entre tiempo y esfuerzo).

    Para el uso interno, los puntos historia pueden ser muy útiles. Incluso para medir la productividad de los sprints. Pero para el trato con los clientes, lo veo más complicado. Sería como decirle a los niños que preguntan cuánto falta para llegar que faltan 250 kilómetros.

  2. Quetzal Oscuro dice:

    Estoy de acuerdo con Andreu Gª. ¿Como traduces puntos de historia a horas o % de avance? Aunque aquí el problema sería hacer ese cambio de mentalidad a querer medir todo en unidades de tiempo que se le puedan explicar, y cobrar, al cliente.

  3. Amigos míos,

    Porque la unidad de tiempo que usas es el Sprint, y lo que haces de esta manera es ver “qué te cabe en el Sprint”, medido en puntos historia.

    El avance es en puntos historia pendientes, con la velocida (media o intervalo) puedes calcular el número de Sprints….

    Ahor bien, dicho esto, todo lo anterior hasta podrías no usarlo, huele a proyecto clásico con requisitos más o menos cerrados, y realmente podrias ir a un modelo en el que lo que importa no es la estimación, ni la hora, ni la dedicación, lo que importa es el valor de verdad añadido al producto #NoEstimates pero el mundo aún no está preparado para ello.

    Saludos

  4. Jonathan dice:

    Andreu Gª quizás la respuesta correcta sería indicarle al cliente que esa tarea se encuentra en desarrollo y estará lista en la próxima versión o release. De esta forma dejas tranquilo al cliente con sus requisitos.

    Saludos

  5. Gabriel dice:

    Buenas tardes a todos,

    Una figura muy importante que nos tiene que ayudar a informar al “cliente”, a contestar a las preguntas al cliente que nos estamos planteando es el Product Owner. Es un rol que conoce como el resto del equipo las implicaciones / las características de una metodología Ágil. Dicha figura como parte del rol cliente es quien sabe las prioridades de cada “requisito”, qué requisitos están incluidos en el sprint en vuelo, cuáles van estar incluidos (posiblemente) en el siguiente sprint, etc.

    Saludos. Gabriel

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top