El desafío de estimar

Snappler
Snappler
Published in
2 min readMay 23, 2022

Estimar es parte de las tareas más importantes y a la vez más complejas del trabajo, por eso desde Snappler armamos una Lightning Talk para resolver este acertijo.

✍🏻 Matías Delle Donne

Mati nos contó que en un principio cuando aún no tenía tanta experiencia o herramientas para estimar, solía creer que podía resolver la issue en el mismo día por lo tanto no daba una aproximación en horas.

En general cuando estimamos no sabemos cuánto tarda una tarea y en ocasiones nos olvidamos por cuánto tiempo la estimamos, entonces después no podemos comparar con el tiempo real que tardamos en realizarla.

Estimar los sprints de la siguiente manera puede ser útil para acertar lo mejor posible:

> En primer lugar conocer la historia del usuario

> Luego no quedarse con la primera estimación, sino ir chequeando el tiempo real de cada issue

> Finalmente repasar el flujo de la issue

Usar un excel con la descripción completa de la historia del usuario y diferenciar la estimación entre devs y diseño (para tener en cuenta el tiempo que les diseñadores necesitan) son dos claves a tener en cuenta para lograr la estimación más cercana.

De la experiencia logramos recolectar estos errores comunes que suceden a la hora de estimar:

  • “Lo termino en el día” > Esto no es correcto hasta que no se revise todo el flujo
  • No estimar los defectos > Puede haber problemas que debemos solucionar
  • Ser muy optimista > Creer que la estimación que hicimos no va a tener errores
  • Ser muy pesimista > Considerar que no sabemos estimar y no volver a revisar el flujo
  • No descomponer el proyecto en tareas concretas > Es necesario ver las tareas específicas de cada issue para revisar el flujo
  • No revisar qué tan cerca estuvimos del estimado original > Es clave volver a chequear cuánto estimamos y cuál fue el tiempo real para luego tener en cuenta ese flujo en otros proyectos

También recomendamos estimar la tarea por un lado y el testeo por otro debido a lo que implica el test de QA o del proyecto mismo, luego en conjunto ver la suma de las dos estimaciones.

Para cerrar, la mejor recomendación que hacemos es estimar entre dos o tres siempre, esto es mucho mejor para poder debatir los puntos de vista de diferentes tareas.

--

--