Una de las tareas más complicadas para los equipos Scrum, suelen ser las estimaciones, un elevado número de factores a tener en cuenta, hacen que la elección del método con el que realizamos las estimaciones sea uno de los aspectos más difíciles de determinar para el equipo de desarrollo.
QUÉ ES LA ESTIMACIÓN EN SCRUM?
En primer lugar y antes que nada debemos recordar que seguramente utilizamos Scrum, porque estamos desarrollando un producto complejo, en un entorno empírico, con mucha incertidumbre, por ello como resultado de las estimaciones obtendremos una probabilidad de completar el trabajo en un período determinado.
En consecuencia, los developers, al estimar un artículo, no se están comprometiendo a entregar el trabajo terminado al final del período de pronóstico, ya que son demasiados los factores (internos y externos) que influyen en el tiempo de desarrollo del producto.
No debemos de olvidar que el Product Backlog es un artefacto vivo y si le pide a los developers que calculen el mismo elemento de la Lista de Producto en momentos diferentes, muy probablemente obtendrán valores diferentes. Ya sea por qué:
El elemento que está al final del Product Backlog, tiene menos detalles y, por lo tanto, su estimación estará más a un nivel macro, que después de que el Product Owner haya preparado el ítem para ser desarrollado en el próximo Sprint, dotándolo de un nivel de detalle mucho mayor y, en consecuencia, haciendo su estimación más precisa.
Porque los desarrolladores han adquirido mayor conocimiento de los requisitos y su valoración es diferente.
Circunstancias técnicas como un avance en la arquitectura o la aparición de errores no contemplados, facilitarán o complicarán la resolución del problema.
Por esta razón, si la empresa elige adoptar Scrum, es importante que todos los Stakeholders estén consciente de que las estimaciones sólo deben considerarse una previsión y no un compromiso de entrega.
ESTIMACIONES SEGÚN LA GUÍA SCRUM
Ya entrando en el ambito del tipo de estimaciones, la Guía Scrum nos dice que los elementos del Product Backlog tienen los atributos de descripción, orden, estimación y valor.
La guia scrum también especifica que solo los desarrolladores son responsables de realizar la estimación.
Pero en ningún momento, prescribe el uso obligatorio de una técnica para hacer estimaciones. Por lo tanto, los developers puede definir cómo se hará la estimación de los elementos del Backlog del producto.
Existen varios tipos de estimaciones que se pueden utilizar en un proyecto ágil, y el tipo adecuado dependerá de las necesidades y circunstancias del proyecto y del equipo.
TÉCNICAS DE ESTIMACIÓN EN SCRUM
Cuando implementamos Scrum en un equipo o incluso en la empresa en su conjunto, podemos utilizar la técnica de estimación que mejor se adapte a nuestra realidad, ya que el uso de una técnica específica para este propósito nunca se menciona.
Actualmente, las técnicas de estimación más utilizadas son:
Puntos de historia: Los puntos de historia son una medida de esfuerzo utilizada para estimar el trabajo en un proyecto ágil. Se utilizan para asignar un valor numérico a cada tarea o entregable, lo que permite a los equipos planificar y priorizar el trabajo de manera más efectiva.
Horas ideales: Las horas ideales son la cantidad de tiempo que se supone que un miembro del equipo debería dedicar a una tarea o entregable. Esta medida de estimación se utiliza a menudo para establecer objetivos y expectativas para el trabajo del equipo.
Puntos de complejidad: Los puntos de complejidad son una medida de la complejidad de una tarea o entregable. Se utilizan para asignar un valor numérico a cada tarea en función de su complejidad, lo que permite a los equipos planificar y priorizar el trabajo de manera más efectiva.
T-shirt sizes: Las tallas de camiseta son una medida de la complejidad de una tarea o entregable en términos de tamaño. Se utilizan para establecer una línea base para la estimación y para comparar tareas entre sí.
La estimación por componentes: Es una medida de la complejidad de una tarea o entregable en términos de los componentes o partes del sistema que afecta. Se utiliza para establecer una línea base para la estimación y para comparar tareas entre sí.
ESTIMACIÓN CON STORY POINTS
User Story es la técnica más utilizada para describir los requisitos al adoptar Scrum. En consecuencia, la estimación de estas historias se suele realizar utilizando una unidad de medida relativa, conocida como Story Points.
Decir que es una unidad basada en esfuerzo relativo, significa que se estiman las tareas basándose en otras tareas ya estimadas o en una historia de referencia (generalmente la de menor tamaño).
Es por eso por lo que a medida que avanza un proyecto, las estimaciones pueden llegar a ser más precisas, gracias a un mayor conocimiento real.
En esta técnica no buscamos determinar inicialmente el número de horas que requiere el cumplimiento de cada requisito (HU), sino su dificultad. Lo que nos permitirá conocer el grado de complejidad que representa el proyecto globalmente, facilitando al Product Owner la priorización de Product Backlog y abriendo diálogos y entendimiento compartido acerca de los requisitos a completarse.
Eso no quita que algunos utilicen esta técnica identificar el tiempo que lleva resolver X puntos de historia y aplicar una estimación paramétrica, para determinar el tiempo, o para establecer como medida de productividad del equipo.
Una estimación paramétrica es que se suele utilizar en proyectos donde existe un bajo índice de variabilidad entre uno y otro, por ejemplo se suele utilizar mucho en construcción.
ESTIMACIÓN CON DÍAS IDEALES
Otra opción mencionada son los días de ideas (u horas ideales), que es una técnica de estimación absoluta, donde se asigna una unidad de tiempo a una actividad, sin hacer comparaciones.
Cuando optamos por utilizar esta técnica, debemos asumir las siguientes premisas:
El elemento del Product Backlog que se estima será solo en base a el esfuerzo del developer que realizará el trabajo.
Cuando comienza el trabajo, todos los recursos necesarios para realizar el trabajo deben estar en posesión del developer.
No habrá interrupciones durante la ejecución de la tarea.
Por lo tanto, para que un elemento del Product Backlog estimado en 2 días ideales se desarrolle de manera efectiva en 2 días, el developer necesita comenzar el trabajo teniendo a mano todos los recursos necesarios para su ejecución, debiendo trabajar 8 horas diarias, sin interrupciones.
Esta técnica describe son los días que el equipo estima que necesita para completar un objetivo, sin considerar otras actividades o interrupciones.
Por eso muchos equipos al realizar este tipo de estimaciones suelen aplicar un factor de corrección de entre 60 % y 70 %, sumado a un extra de sucesos o tareas no contempladas para poder traducirlo a lo que se denominan “días reales”.
Profundizaremos en estas y otras técnicas de estimación ágil en nuestro siguiente post, donde también veremos algunos métodos de estimación como:
Método Delphi en Scrum.
Estimación por afinidad.
Estimación con talla de camisetas.
Votación por puntos.
Lectura recomendada: