Cuando empezamos un proyecto, como ingenieros tendemos a subestimar el esfuerzo para entregarlo y damos una fecha de entrega optimista. Después esa fecha se convierte en un compromiso y puede llevar a horas extra en el equipo de ingeniería y a frustración para el cliente o los stakeholders cuando hay un retraso. La falacia de la planificación explica este fenómeno y por tal motivo podríamos sentirnos tentados a no dar estimaciones, pero los clientes y stakeholders quieren saber cuándo se entregará el proyecto porque con base en eso pueden hacer planes.
El objetivo de este documento es definir un proceso de estimación efectivo y consistente, así como mostrar una forma clara de transformar las estimaciones en tiempo. Los elementos que necesitamos son esfuerzo, story points y velocidad. Son términos conocidos pero vale la pena revisarlos porque pueden tener significados diferentes para cada desarrollador.
Esfuerzo
Para ciertas actividades, como vuelos o entregas de comida, tenemos estimaciones precisas porque son procesos que se han realizado miles o millones de veces y la variabilidad es baja. Pero en desarrollo de software trabajamos con tareas únicas que tienen su propia complejidad, riesgo o incertidumbre, y obtener una estimación no es trivial.
Una forma de descomponer el esfuerzo en desarrollo de software es considerarlo como la suma de riesgos o incertidumbres, complejidad y cantidad de trabajo requeridos para implementar por completo y potencialmente liberar una historia de usuario.
Cantidad de trabajo
La cantidad de trabajo es el número de tareas o cambios definidos que se requieren para completar la historia. A veces estas tareas se pasan por alto porque son actividades sencillas y menores; sin embargo, en algunos casos representan una parte importante de la funcionalidad.
Riesgo o incertidumbres
Este es el factor más variable del proceso de estimación. Cuando algunas incertidumbres no se resuelven, pueden llevar a un aumento del alcance; y cuando los riesgos no se abordan, el proyecto puede desviarse. Estos son algunos escenarios que deberíamos evitar antes de dar una estimación:
- no tenemos especificaciones completas
- el enfoque de implementación no es claro
- trabajamos con código legado que es difícil de entender o requiere configurar el entorno
Complejidad
La complejidad de una historia puede aumentar cuando:
- hay componentes o repositorios dependientes
- trabajamos en proyectos nuevos
- tenemos múltiples reglas de negocio
No existe una fórmula exacta para combinar los factores anteriores, pero conforme adquirimos más práctica y participamos en las discusiones podemos mejorar nuestras estimaciones. Lo importante es no olvidar incluir los tres factores en la estimación.
Story points
Para medir el esfuerzo usaremos los story points, que son una unidad objetiva y relativa que asignamos a cada historia de usuario. Los story points son una función del esfuerzo. Esta es la fórmula:
story points = f(cantidad de trabajo, riesgo o incertidumbre, complejidad)Es importante notar que los story points son una unidad relativa. Esto significa que cada proyecto o equipo necesita definir su propia escala. Podemos definir una escala para el equipo para crear un roadmap o una línea de tiempo.
Una práctica común es utilizar números de Fibonacci para estimar, porque la incertidumbre crece con el tamaño y la complejidad del trabajo, por lo que las estimaciones precisas pierden sentido en tareas más grandes.
Como los story points son una unidad relativa, estos son algunos ejemplos de historias de diferentes tamaños.
Historias de 1 story point
Este es el tamaño más pequeño. Para que una historia sea de 1 punto debe tener bajo riesgo o incertidumbre y ser un cambio en un componente existente.
Historias de 2 story points
Un cambio a un componente existente en múltiples repositorios o archivos. También componentes nuevos construidos sobre componentes existentes.
Historias de 3 story points
Puede ser una mezcla de cambios a componentes existentes y creación de componentes nuevos.
Historias de 5 story points
Historias que crean una sección nueva o que tienen alta complejidad o incertidumbre.
Historias de 8 o más story points
Cuando tenemos una historia de 8 puntos o más debemos intentar dividirla en historias más manejables. Pero si al dividirla no se aporta valor al usuario o no existe un entregable, podemos trabajar en ella completa.
Velocidad
Podemos definir la velocidad como el número de story points completados en un sprint determinado. Esta métrica nos da un número estimado de sprints que podría tomar completar una historia, según el número de puntos. La fórmula es:
número de sprints = story points / velocidadEn circunstancias normales, podemos decir que cuando se completen los sprints estimados tendremos nuestra funcionalidad entregada y podremos convertirlo en una fecha potencial de liberación.
Por otro lado, también podemos usar la velocidad del equipo para definir el trabajo comprometido en cada sprint.
Cono de incertidumbre
Ya hemos definido algunas formulas, pero el resultado es tan bueno como sus datos de entrada. El problema es que no podemos conocer todos los datos con 100% de certeza hasta que el proyecto está terminado. Al inicio de un proyecto hay más incógnitas y, conforme trabajamos en él, aprendemos más sobre el alcance, los riesgos y el enfoque técnico.
Este es el cono de incertidumbre. Mientras más conocemos el proyecto, mejor estimación podemos proporcionar. El cono no debería ser una razón para evitar las estimaciones, pero explica por qué una estimación al inicio de un proyecto tiene más variabilidad que una estimación para un proyecto que está listo para comenzar.
Para manejar esta variabilidad, podemos:
- Dar actualizaciones periódicas y ajustar las estimaciones conforme aprendemos más sobre el trabajo.
- Usar rangos en lugar de fechas fijas. Por ejemplo, podemos decir que una funcionalidad tomará de 12 a 16 días, en lugar de exactamente 14 días.
El punto importante es que una estimación no es un compromiso hecho una sola vez al inicio de un proyecto. Es nuestra mejor predicción basada en la información disponible en ese momento. Conforme disminuye la incertidumbre, debemos revisar la estimación y acotar el rango.
Esto hace explícita la incertidumbre en lugar de ocultarla detrás de un número aparentemente preciso. Las estimaciones tempranas deberían tener rangos más amplios, mientras que el trabajo que se entiende bien y está listo para comenzar puede estimarse con mucha mayor confianza.
Estimaciones más efectivas
Hasta ahora nos hemos enfocado en estimar el trabajo, pero una estimación también necesita considerar al equipo y los recursos disponibles para entregarlo. Una vez que entendemos el esfuerzo estimado y la velocidad del equipo, podemos comparar la estimación con las expectativas de los stakeholders y las restricciones del negocio.
El triángulo de gestión de proyectos ayuda a explicar estos trade-offs. Alcance, tiempo y costo están conectados: fijar o cambiar uno de ellos normalmente requiere ajustar al menos uno de los otros. La calidad debe seguir siendo parte de la definición de terminado, en lugar de convertirse en un trade-off implícito.
Dependiendo de cuál variable es más importante, podemos usar diferentes estrategias.
Tiempo fijo
Si la restricción más importante para la empresa es entregar una funcionalidad en una fecha específica, podemos ajustar el alcance o el costo. En mi experiencia, esta es la solicitud más común de los stakeholders. El alcance necesita una línea clara entre lo que se requiere para la liberación y lo que sería bueno tener.
Las estrategias posibles son:
- Entregaremos la funcionalidad requerida para la fecha objetivo y moveremos la funcionalidad deseable a una liberación posterior.
- Entregaremos el alcance completo para la fecha objetivo, pero tendremos que agregar X ingenieros más al proyecto.
Alcance fijo
Cuando se requiere el alcance completo, debemos aceptar variabilidad en los otros factores. Como nos comprometemos a entregar todas las funcionalidades, la fecha de entrega debe permanecer flexible. En este caso es mejor dar un rango en lugar de una fecha exacta, especialmente cuando todavía hay incertidumbre en la estimación.
Las estrategias posibles son:
- Entregaremos el alcance completo en aproximadamente X días, con una variabilidad de +/- Y días.
Costo y oportunidades
Las empresas naturalmente intentan optimizar costos, pero en mi experiencia las estimaciones rara vez se expresan en términos de costo. Normalmente hablamos de cuánto tardará un proyecto o qué alcance podemos entregar, en lugar de cuánto costará.
El costo también se superpone con el tiempo, ya que el tiempo de desarrollo es en sí mismo un recurso y normalmente uno de los más escasos. Sin embargo, pensar explícitamente en el costo puede abrir formas alternativas de resolver el problema, en lugar de solo ajustar el alcance o la fecha de entrega.
Para este factor podemos considerar opciones como:
- Podríamos no necesitar desarrollar la funcionalidad internamente y usar un servicio de terceros.
- Podríamos simplificar el proceso, explorar un enfoque técnico diferente o involucrar a un ingeniero con más experiencia en el dominio del problema.
Las “estimaciones precisas” son un oxímoron
Una estimación es, por definición, una aproximación basada en la información disponible en un momento determinado. Si supiéramos exactamente cuánto esfuerzo requerirá un proyecto y cuándo estará terminado, ya no sería una estimación.
Esto no significa que las estimaciones no sean útiles. Su valor no está en predecir el futuro con precisión milimétrica, sino en hacer explícita la incertidumbre y proporcionar suficiente información para planear, priorizar y hacer trade-offs.
Las estimaciones deberían ayudar a los equipos y stakeholders a tomar decisiones, no a crear compromisos artificiales. Cuando las expectativas y las estimaciones no se alinean, alcance, tiempo y costo nos dan diferentes palancas para encontrar un plan realista.
El objetivo no es estimar perfectamente, sino comunicar lo que sabemos, lo que no sabemos y las opciones que tenemos.
Recursos: