La estimación de requerimientos es uno de los procesos más importantes que tiene un equipo de tecnología.

Si bien puede no ser muy atractivo restar tiempo al desarrollo para poder determinar cuánto esfuerzo tomará cada tarea, la realidad es que el valor de estimar es evidente.

En un contexto de objetivos y compromisos externos, es necesario poder responder al “cuándo” de las distintas iniciativas para comprender los recursos que requieren y qué tan bien se adecúan a los plazos de la estrategia.

De todas formas, si bien la estimación en sí tiene un propósito noble, la realidad es qué muchos equipos caen en un problema recurrente: las estimaciones iniciales no se respetan y se cae en la re-estimación constante.

Debido a que el valor de la estimación tiene que ver con poder determinar, de antemano, qué esfuerzo y recursos demandará una tarea, sí sucesivamente las estimaciones originales no son más relevantes, entonces la credibilidad en el proceso disminuirá.

Re-estimar no es un problema en sí, ya que es imposible saber de antemano todas las particularidades que tendrá la ejecución de una tarea. Especialmente tareas más complejas o con un nivel elevado de incertidumbre. Es algo que pasa.

El problema es cuándo la re-estimación comienza a ser una práctica presente en todo el equipo. Eso ya denota un problema en los procesos.

Cuando se re-estiman incluso las pequeñas tareas de bajo esfuerzo y baja incertidumbre.

Esto es lo que lleva a muchos equipos, que han definido un alcance funcional fijo para su producto, a correr las fechas de lanzamiento una y otra vez hasta tener el trabajo terminado.

Es algo que, lamentablemente, pasa más frecuente de lo que uno espera.

Por esta razón, te traigo una alternativa que busca resolver el problema de la procrastinación que viene por la re-estimación constante: el concepto de “Appetite”, desarrollado en la metodología Shape Up.

Este concepto es simple pero a la vez poderoso:

En vez de fijar un alcance y calcular cuánto esfuerzo va a tomar, haz qué el tiempo sea fijo y el alcance variable.

Se trata de invertir la forma en la qué usualmente los equipos de producto trabajan.

Lo que sucede, en muchos casos, es que se define un MVP con 4 funcionalidades clave (alcance fijo), y el equipo estima inicialmente que tomará 2 meses en completarse.

Pero, luego, a mitad de proyecto, el equipo se encuentra con una complejidad adicional que no ha sido contemplada en la estimación.

Así, la estimación del MVP se ajusta a 2 meses y 3 semanas para poder dar respuesta a esta complejidad.

Cerca del lanzamiento, un miembro clave del equipo cae enfermo y esto atrasa al proyecto por 2 semanas más.

Debido a que el alcance del MVP es fijo, la única variable realmente flexible es el tiempo, por lo que ahora pasa a costar 3 meses y 1 semana.

35 días después de lo planificado inicialmente, el equipo puede lanzar el MVP.

¿El problema? → dejar el alcance fijo dejó al equipo sin la capacidad de negociar, lo que lleva a experimentar un incremento del esfuerzo necesario, que a su vez representa un costo de oportunidad para la empresa.

Esta forma de trabajar parece ser conveniente para ambos grupos involucrados.

• Los stakeholders tienen claridad acerca de qué esperar (alcance fijo).
• Los desarrolladores se guían con estimaciones propias en lugar de un deadline exigente bajado por dirección (posibilidad de ajustar estimaciones).

Resulta que, en la práctica, esto lleva muchas veces al efecto opuesto de lo que uno desea: la procrastinación indeterminada de un lanzamiento de producto y elevados costos no previstos.

Para evitar caer en la trampa de la re-estimación permanente, habilita la negociación del alcance y compromete una fecha con tu equipo.

Si bien los compromisos de fecha pueden ser un poco incómodos, la realidad es que lo son cuando el alcance está fijo.

Aquí, no se quiere caer en el escenario de “Entrega X en Y”, ya que debido a la complejidad e incertidumbre natural del desarrollo de software (que afecta a roles de distinto seniority), las cosas pueden cambiar a medida que se conoce más acerca del proyecto.

Tampoco sirve establecer una fecha muy lejana en el futuro.

Fijar un día de lanzamiento de aquí a 6 meses no tiene sentido, ya que las estimaciones son relevantes únicamente en el corto plazo.

El famoso concepto del “cono de la incertidumbre” explica que al inicio de un proyecto, estimar a largo plazo y fijar una fecha específica no tiene sentido ya que, debido a todo lo que se desconoce, la variabilidad en los tiempos de entrega es muy elevada.

Por tal razón, establecer un tiempo fijo de ejecución, inamovible e innegociable, debe ser algo que pertenezca al corto plazo. Por ejemplo, no más de 6 semanas.

En cuánto al alcance funcional, cómo ahora será variable y negociable, debe contener para cada funcionalidad o iniciativa una prioridad y esfuerzo establecido.

Esto guiará el orden de ejecución.

Las tareas más prioritarias son usualmente las que pertenecen al flujo crítico y que deben estar para poder entregar valor directo al usuario. Las siguientes tienen más que ver con mejorar la experiencia de usuario, sobre la base de un servicio que ya se brinda.

Ahora bien, la estimación de tareas no deja de hacerse.

Las tareas que formen parte del alcance deben ser estimadas igualmente, ya que debemos dimensionar el esfuerzo de cada una para comprender qué podemos llevar a cabo en el tiempo que disponemos.

La cuestión es que ahora, la estimación pasa a ser una guía que orienta al equipo en vez de un compromiso de entrega.

Establecer un tiempo fijo centra al equipo a cuidar los recursos que dispone y delimitar el esfuerzo que desea invertir en cada idea.

Justamente, el concepto de “Appetite” responde a la pregunta: ¿cuánto esfuerzo y recursos deseo invertir en esta idea o lanzamiento de producto?

En base al ejemplo anterior del MVP, el equipo en vez de estirar su lanzamiento por 5 semanas más de lo previsto (lo que representa un gran costo de oportunidad), directamente flexibiliza lo qué se va a entregar, quizás reduciendo el alcance de algunas iniciativas o descartando las tareas menos prioritarias.

No se trata de eliminar el proceso de estimación, sino darle un nuevo propósito.

Las fechas de entrega no se determinan en base a las estimaciones y re-estimaciones, sino que están determinadas por la cantidad de trabajo que deseamos ejecutar.

Y, sí el equipo ve que la entrega se complica, en vez de estirar esa fecha, puede ajustar el alcance del proyecto.

Lógicamente, siempre y cuando, este siga sirviendo al objetivo y entregando valor tangible al usuario.

Dicho esto, te invito a que pruebes invirtiendo la relación alcance-tiempo en tus proyectos y veas cómo tu equipo se adecúa a ello.

Quizás puedas resolver algunos problemas que arrastras hace tiempo.

¡Muchos éxitos!