.

Estimación en Scrum. La triangulación

Al realizar la estimación, cuando comparamos los puntos de historia con la historia de referencia y asignamos los puntos de historia esperamos que sean comparables entre sí. Por ejemplo, si la historia A tiene 5 puntos de historia y la historia de B tiene 10 puntos, esperamos B conlleve el doble de esfuerzo.

Ninguna estimación es perfecta y a veces es posible que los valores estimados sean incompatibles. Para estar seguro sobre la estimación puedes confirmar los valores  mediante una comparación doble con historias reales, y posteriormente hacer los ajustes necesarios.

Otra forma de mejorar las estimaciones es teniendo múltiples historias de usuario de referencia en función de su tamaño, y utilizarlas para estimar cada historia de usuario. Por ejemplo, puedes tener una historia de referencia de 1 punto y otro de 10 puntos. Cuando comparas la historia objetivo con la primera referencia (1 punto) y decides que se necesitan cinco veces el esfuerzo (5 puntos de historia), también debes compararla con la segunda referencia (10 puntos) y ver si se necesita la mitad de esfuerzo.

Estas comprobaciones dobles que se emplean para aumentar la fiabilidad de las estimaciones, se conocen como triangulaciones.

Tabla de triangulaciones

Una muy buena práctica para triangular las estimaciones es utilizar una tabla con columnas para cada valor y colocar las tarjetas de las historia de usuario (o notas adhesivas) en su correspondiente columna, en función de la estimación asignada. En este caso, logramos una comparación completa entre todas las historias y será mucho más fácil encontrar cualquier problema al respecto y solucionarlo.

Tabla-de-triangulaciones

Esta forma de estimar es muy similar a la estimación por afinidad, que explicaremos a continuación.

Estimación por afinidad

Estimar por afinidad es a veces una buena opción. En esta práctica, el equipo empieza clasificando las historias en función del esfuerzo relativo que requieren de menor a mayor, o viceversa.

Estimación por afinidad – Clasificar

estimacion-por-afinidad

 

Cuando ya están clasificados, se  agrupan en función de su valor estimado (puntos de historia).

Estimación por afinidad – Agrupar

estimacion-por-afinidad-agrupar

Horas ideales/ Días ideales

A pesar de que los puntos de historia es la manera preferida para estimar, algunos equipos ágiles usan en su lugar “horas ideales” o  “días ideales”, porque es más fácil de entender y explicar. En este caso, se estima la cantidad de tiempo requerido para cada historia de usuario en una situación ideal.

Cuando comenzamos a trabajar, podemos medir la velocidad y entender cuánto tiempo ideal podemos disponer en cada Sprint. Por ejemplo, un equipo de 7 miembros que trabaje 20 días en un Sprint tiene 140 días reales en cada Sprint (tiempo transcurrido), mientras que podría ser capaz de entregar sólo 100 días ideales.

la diferencia entre tiempo real e ideal es fundamental a la hora de realizar las estimaciones. Mientras que la primera se refiere a la totalidad de la jornada laboral,  el tiempo ideal se refiere al tiempo de trabajo en condiciones ideales, esto es, eliminando todo lo que no es estrictamente “trabajo”, suponiendo que no hay ninguna pausa por interrupción o atención de cuestiones ajenas a la tarea y que la persona se encuentra en buenas condiciones de concentración y disponibilidad.

A la hora de estimar es una mejor utilizar puntos de historia, ya que el uso de horas/días ideales  crea expectativas que a su vez pueden conducir a asignar responsables y señalar culpables.

Reestimar

Las estimaciones que hacemos no están escritas sobre piedra, y podemos volver a realizarlas para resolver algún malentendido o como consecuencia de nuestro mayor conocimiento del proyecto; a medida que vayamos adquiriendo más experiencia en el proyecto, nuestras estimaciones serán más precisas.

Las estimaciones son sólo una comparación del esfuerzo relativo requerido para llevar a cabo una historia de usuario, y por ello solo una mejor comprensión sobre la historia de usuario en cuestión justifica la reestimación.

En la mayoría de entornos Agiles sólo las historias de usuario del Backlog de Producto son re-estimadas ya que tan pronto como se mueven al Backlog del Sprint o se completan, y ya no volvemos a estimarlas. Si no se completan vuelvan al Backlog de Producto, y entonces son reestimadas de nuevo.

Debemos  considerar que las estimaciones incluyen todo los elementos del entorno del proyecto, no necesitamos considerarlas por separado. Es decir, si entendemos que la actitud del cliente no es tan colaborativa como se esperaba, no necesitamos aplicarlo a la estimación por separado, pues esta circunstancia del entorno ya está incluida en sí misma en la estimación. La mayoría de los errores de estimación se dan por los cálculos de velocidad.

 

Deja un comentario

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

AUTOR:  miguel

Dirección proyectos TI y #ecommerce bajo Prince2 o Scrum . Usabilidad, Conversión, Seo, AdWords, Marketing online, Analítica. Consultor y desarrollador.

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR