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

Actualización: Este post es antiguo, después acabamos descubriendo mejores maneras de trabajar, y que funciona mejor no usar Puntos Historia, que conllevan desperdicio (te dejo post actualizado que explica esto), o que si los usas que sea sólo para estimar, la velocidad mejor contarla en número de Historias que se han convertido en Working Software o Solutions (si no trabajas en software), te dejo un vídeo más reciente que actualiza esta información.

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 un ítem, típicamente, una Historia de Usuario, 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»

Una analogía para estos casos (podéis leer más aquí, el ejemplo es del blog de Crisp), para entender los problemas de usar «tiempo», es comparar los Puntos Historia con la duración de un viaje con niños, en coche, en el que los niños nos suelen preguntar: ¿Cuánto falta para llegar?
Y, realmente, con exactitud, no sabes que responder. El caso es que tú sabes la distancia (tamaño), pero no puedes predecir si habrá retenciones o paradas inesperadas, así 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 modelo de trabajo á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. 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.

13 comentarios en “¿Por qué utilizamos Puntos Historia para estimar y no horas?”

  1. 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.

    1. que buena analogia , comparto tu observacion a la luz de planes y presupuestos con planes de trabajo compuestos entre diferentes actores y modelos de trabajo, esto no te va a resultar. Tampoco entendiendo que en la actualidad el 90% de industrias su arquitecturas tienen componentes legacy. Asi que si quiere entregar un valoración a un cliente en terminos de tiempos y costo este metodo no es el mas preciso se debe buscar un mix.

  2. 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

    1. interesante planteamiento, en las arquitecturas de multiples plataformas legacy en las cuales se deben establecer compromisos en terminos contractuales , o terminos reglamentados en cada pais donde te ponen una fechas limite con alcances cerrados claramente no es el metodo esperado. Es la recomendacion que esperamos de los coach agiles hablar con transparecia ante estos plantemientos y dificultades de la industria.

  4. 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. 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

  6. No debería ser un problema para el usuario, ya que además de tener los sprints, debemos de contar con un calendario de liberaciones o releases y/o mapear los momentos en los que debamos realizar las demos, en las que podemos hacer partícipe al usuario y/o las UAT que podrían realizarlas previas a las liberaciones o incluso por cada sprint. en realidad considero que la principal barrera es el nivel autogestión que pueda tener el equipo para trabajar de manera eficiente sin ser auditado por algún project manager, ese considero que es un factor determinante.

  7. Samuel Palacios

    Sigo sin ver la ventaja de valorar con Puntos Historia en lugar de horas de trabajo «ideales» (entendiendo por ideales que una persona trabaja sin interrupción y disponiendo de toda la información, sistemas en marcha,…). Según la comparación realizada: «la distancia serían los Puntos Historia». Esto podría ser válido si, así como para medir la distancia existe un patrón que es el metro, existiera un patrón de Puntos Historia.

    1. De acuerdo pasa por moda y generalmente quien no esta sentado en la responsabilidad tecnica del compromiso en el mundo actual, este metodo la no ser exacto da la posibilidad de equivocarse y eludir la responsabilidad

  8. Los puntos de historia, IMHO, se inventaron para que los equipos de desarrollo no tengan que hacer el mapeo de [cantidad de trabajo, a.k.a valor añadido] a horas de trabajo. De esta manera, son otros departamentos (financiero, por ejemplo) y el cliente, los que se encargan de hacer este mapeo. No olvidemos que una empresa, ya fabrique SW o fabrique tornillos o donuts, necesita estimaciones en horas para poder hacer planes comerciales, de compras, de producción, etc. Para mí, es una delegación que no siempre es posible (porque el cliente manda y no siempre le puedes obligar).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba