Estimación de tiempos de desarrollo, de la intuición al método

may. 15, 2025

¿Para cuándo estará listo?

Cuando alguien en la reunión pregunta «¿para cuándo estará listo?», comienza la parte más arriesgada de cualquier iniciativa de software: la estimación del tiempo.
Incluso en la actualidad, con metodologías ágiles ya maduras y herramientas de automatización en cada etapa del proceso, los retrasos siguen apareciendo en los informes y erosionando la confianza entre equipos, clientes e inversores.

Este artículo es una guía de aterrizaje para:

• Desarrolladores que empiezan y necesitan poner precio (en horas) a sus primeras ideas.
• Start-ups unipersonales que viven con el cronómetro pegado al runway financiero.
• Quienes quieran dar el salto a la gestión de proyectos sin perder el foco técnico.

El objetivo: pasar de «creo que serán dos semanas» a «con un 90 % de confianza, esto saldrá el 7 de junio».

Empecemos entendiendo el problema de raíz.

Conocer el tiempo de desarrollo de un proyecto de software no es un lujo, es un requisito para presupuestar, sincronizar equipos y lanzar al mercado a tiempo, de ello depende su éxito en gran parte. Sin embargo, el software es una diana en movimiento: los requisitos cambian, emergen dependencias y el optimismo natural hace que subestimemos el esfuerzo. El resultado se repite: retrasos, sobrecostes y la confianza de todas las partes erosionada.

Aun así, seguimos necesitando fechas. Sin un horizonte temporal no hay plan, ni inversor tranquilo, ni sprint que priorizar. El reto consiste en pasar de los “palabros” («dos semanitas») a rangos defendibles («el 7 de junio con un 90 % de confianza»), sin convertir la estimación en un ritual eterno. Eso sí, en un ambiente de requisitos cambiantes poca estimación sirve por muy elaborada que sea y planes que se haga, es sumamente importante una buena toma de requisitos y una idea clara de lo que se pretende conseguir.

Antes, estimar era adivinar: una breve historia del caos

La situación era todavía peor hace apenas dos décadas. Faltaban métricas históricas, las integraciones se hacían “a pelo” y muchas de las herramientas actuales ni existían. Sin issue trackers ni git omnipresente, cada entrega era un “Big Bang” y cada retraso se contaba en meses. Hasta que llegaron métodos ágiles, pipelines automáticos y una cultura de medición continua, estimar era poco más que lanzar una moneda al aire.

• 1968 — “software crisis” (Wikipedia) El término nació en la NATO Software Engineering Conference de Garmisch-Partenkirchen. Proyectos militares como IBM OS/360 y los sistemas de control de misiles excedían en hasta ×10 el tiempo y el coste previstos, revelando que las técnicas de la época no daban la talla.

• 1995 — aeropuerto de Denver (Calleam) El sistema automatizado de equipajes del Denver International Airport debía estar listo en 9 meses; acabó tardando casi 3 años y sumó unos 560 M $ al presupuesto. Tras múltiples pruebas en las que las maletas salían despedidas o se aplastaban, el proyecto se recortó a un único sistema de gestión de equipaje y se desmanteló en 2005.

• 2002-2011 — NPfIT británico (The Guardian) El National Programme for IT pretendía unificar la historia clínica electrónica de todo el sistema de salud estadounidense. Partió con 6000M$; terminó cancelado tras gastar 12-13000M$, con enormes disputas contractuales y apenas beneficios clínicos tangibles.

Estos fiascos, entre otros, demostraron que hacía falta un método: algo que convirtiera las corazonadas en números, en algo defendible y realista. Aunque los retrasos suelen deberse también a política, contratos o logística, buena parte del problema está en la fase puramente técnica, en ella nos centraremos, en el desarrollo de software.

Métodos de estimación: convertir la intuición en números

Ya sea una aplicación web, móvil, de escritorio o un sistema embebido, prácticamente todos los proyectos de software comparten bloques comunes y otros específicos. Al estimar, es fundamental diferenciar entre tareas rutinarias, que dominas, y aquellas que requieren investigación o aprendizaje previo.

Este punto es crítico para desarrolladores en solitario: siempre surgirán componentes desconocidos (una pasarela de pago, un servicio de notificaciones, sincronización en tiempo real, etc.). Por ello, debes incluir explícitamente horas de investigación en tu desglose. Si luego decides facturarlas al cliente o asumirlas como inversión personal, dependerá de tu política y negociación.

Algunos de los métodos de estimación que más se usan hoy son los que se muestran a continuación. Aunque es una parte intrínseca, en este artículo no hablaremos de gestión de proyectos, sino de las técnicas que convierten requerimientos en horas o puntos: de las aproximaciones absolutas (horas PERT) a las relativas (story points) y los modelos basados en datos históricos.

1. Estimación absoluta (horas y Three-Point / PERT)

Aquí defines tres escenarios para cada tarea: optimista (O), donde todo va sobre ruedas; probable (M), tu pronóstico realista; y pesimista (P), si surge cualquier contratiempo. Con la fórmula (O + 4·M + P) / 6 obtienes un valor ponderado que suaviza los extremos y ofrece una estimación equilibrada. Ideal cuando trabajas con incertidumbre moderada —ni trivial ni totalmente desconocido— y tu equipo planifica o factura en horas.

2. Estimación relativa (Story Points + Velocity)

En lugar de horas, aquí asignas Story Points (1, 2, 3, 5, 8…) a cada historia de usuario —una pequeña descripción de la funcionalidad— según su complejidad relativa. Luego mides la velocidad (velocity) del equipo, es decir, los puntos completados por sprint, para proyectar cuántos puntos caben en futuros ciclos. Funciona mejor en equipos ágiles consolidados con un histórico de velocidad.

3. T-Shirt Sizing

Para un primer vistazo rápido, clasificas cada tarea o historia con una talla (XS, S, M, L, XL) según su envergadura. Después conviertes cada talla en un rango aproximado de horas o puntos (por ejemplo, M = 5–8 h). Esta técnica agiliza la estimación cuando el backlog es muy amplio y no tiene sentido profundizar en cada ítem de inicio.

Son muchas las técnicas de estimación, pero en mi experiencia con equipos pequeños y proyectos de tamaño medio no hace falta complicarse. Al principio, solía añadir un margen de seguridad mayor porque desconocía la complejidad de muchas tareas; con el tiempo y la práctica he reducido ese colchón. Además, herramientas de medición del tiempo como WorkIO me facilitan mantener un registro del tiempo real invertido en cada actividad, de modo que puedo consultar mis datos históricos y ajustar mis estimaciones con mayor precisión.

Mi método personal: simple, práctico y basado en datos

Lo que yo suelo hacer parte de un principio sencillo, no tiene ningún misterio, baśicamente se trata de dividir el proyecto en las tareas más pequeñas posibles y estimar cada una en horas. Desde la configuración de la base de datos hasta un formulario o un endpoint REST, todo se anota y se suma. Finalmente aplico un factor de contingencia (15–20 %) para cubrir investigación, ajustes y pequeños imprevistos. Sin cálculos complicados ni cartas de Planning Poker, basta un buen desglose y disciplina al anotar cada bloque de trabajo.

Para proyectos de un tamaño tirando a grande, en los que intervengan múltiples departamentos y equipos puede (y debe) ser necesario estimar utilizando metodologías avanzadas, pero para estimar los tiempos de proyectos pequeños o medianos no es necesario utilizar frameworks tan complejos.

Un truco que me funciona muy bien es abordar primero las áreas más críticas y esenciales del proyecto —especialmente aquellas tecnologías o componentes que no domino— dejando todo configurado y operativo aunque aún no esté completamente acabado. Enfrentar lo desconocido al principio me permite dedicar tiempo extra a lo complejo y reservar para el final las tareas más familiares, de modo que se reduce el riesgo de sorpresas de última hora.

Ejemplo práctico: estimar un ecommerce sencillo con pagos

Imaginemos que vamos a desarrollar un ecommerce que incluya pagos, utilizando una pasarela como Stripe por ejemplo:

Por qué este desglose ayuda:

• Al dividir cada formulario y acción CRUD, identificas de forma precisa los puntos de investigación o complejidad.
• Así puedes ajustar el tiempo de seguridad por bloque (p. ej. más investigación en Stripe).

Este nivel de detalle es perfecto para proyectos pequeños o medianos donde cada hora cuenta y el cliente quiere ver transparencia en el desglose.

Estimar mejor es posible (y medible)

Este ejemplo es solo ilustrativo: en proyectos reales es muy probable que debas contemplar otros factores (integraciones adicionales, validaciones legales, revisiones de diseño, tiempos de coordinación con stakeholders, etc.). Lo clave es comprender el proceso:

1. Descomponer tu proyecto en tareas mínimas.
2. Estimar cada una en horas.
3. Sumar y aplicar un factor de contingencia.
4. Medir lo realmente invertido.

Llevar un control riguroso del tiempo es la mejor forma de perfeccionar tus estimaciones futuras. Herramientas como WorkIO facilitan mucho este proceso, permitiéndote comparar estimaciones con tiempo real, detectar desviaciones y ajustar tus coeficientes de buffer. Herramientas de control del tiempo cómo WorkIO te ayudan a cerrar el círculo entre lo estimado y lo realmente ejecutado.

Happy Coding!!