Porque deveremos estimar?

https://onceyougoagile.com/why-should-we-estimate/
Why should we estimate?

Por qué debemos estimar? ¿Qué variables consideramos durante la estimación? Las estimaciones se hacen más precisas cuanto mayor es la frecuencia de la práctica, manteniendo el mismo equipo constante. ¿Qué y cómo podemos estimar? Podemos hacer esto a lo largo de los diferentes niveles de la jerarquía de requisitos, desde niveles estratégicos hasta la deimplementación. Pero una buena planificación de producto debe realizarse por etapas, aumentando el valor del producto e introduciendo complejidad a lo largo de las diferentes fases de desarrollo.

Qué se considera al estimar?

Estimar una user story corresponde a un proceso analítico que considera diferentes variables:

  • la complejidad de la implementación,
  • el tiempo para concluirlo,
  • dependencias de terceros para reunir toda la información o los requisitos previos necesarios,
  • toma en consideración quién va a implementarlo, cuál es el equipo, cuál es el miembro del equipo, su experiencia con este tipo de tarea y / o tecnología,
  • y otros factores diferentes, dependiendo del caso específico.

 

La precisión de la estimación es una cuestión de práctica regular

La estimación en sí puede expresar una promesa, pero, esencialmente, las estimaciones deben dejar el equipo confiado. Significa que aceptan en el sprint esa responsabilidad, creen que encaja en su capacidad. Una vez más, la capacidad se mide en story points. Si la historia se estima en un valor muy alto. entonces debe haber un esfuerzo para simplificar o especificar el ambito, de forma que el equipo la comprenda y la pueda implementar en un sprint.

Cuanto más frecuente la práctica de la estimación, más precisa se convertirá. Estimar regularmente es una manera de mejorar la previsibilidad y ajustar las expectativas a la velocidad o capacidad media. Es muy importante tener una base histórica para tomar decisiones. Recoger regularmente estimaciones nos da esa base temporal, para corrección y ajuste, confiando más a lo largo del tiempo en la capacidad del equipo para estimar.

Recordando un post anterior: un backlog que nunca fue estimado es una lista de tareas que no sabemos cuánto cuesta y cuándo estará listo.

Qué y cómo podemos estimar?

La estimación se puede realizar en todos los niveles de cartera de productos: Sagas, Épicos, Historias, Tareas y Sub-tareas.

La práctica de estimación se puede realizar a través de diferentes métricas. Los puntos de referencia o los tamaños de los tamaños son los más comunes. Pero, en realidad, en mi opinión, podemos usar ambos en diferentes momentos en el tiempo y para diferentes niveles de requisitos. Por ejemplo:

Si estoy estimando en el nivel Saga o Épico, sin una profunda y detallada discusión de refinamiento, voy a usar las camisetas de los tamaños.

Yendo al detalle, dividiendo el requisito funcional en las discusiones de implementación y sub-tareas, es más común, estimar a través de Story points.

Si ya estamos ejecutando un release en sprints, refinando regularmente user stories, tasks y sub-tasks, discutiendo opciones de implementación, básicamente haciendo un refinamiento eficiente, es mejor hacerlo con story points.

Con base en mi experiencia es: usamos las camisetas de tamaño a nivel de la cartera y los puntos de referencia en el nivel del producto para que podamos estimar user stories, tasks y sub-tasks. Un backlog estimado en story points facilita el proceso de estimar otros niveles de requisitos (Epics y Sagas) para la planificación de futuros releases.

Pero también podemos estimar con otras métricas, basadas en costos y tiempo: costo por hora / día. Jira también lo permite.




Por qué estimamos?

Normalmente estimamos para poder prever más precisa y correctamente a lo largo del tiempo, si se mantiene el mismo equipo.

La precisión en la estimación es importante porque necesitamos saber cuánto somos capaces de producir con los recursos actuales, lo que significa que sabremos cuál es nuestro MPP (Minimum Possible Product), y podemos compararlo con el MVP (Minimum Viable Product), identificando si nuestra capacidad es suficiente o cuál es la inversión requerida.

En Agile, el equipo de desarrollo se compromete con el propietario del producto a entregar un cierto volumen de user stories. Pero eso no significa que, en el primer release, sea lanzado el concepto de producto ideal. Dada la incertidumbre y la presión para avanzar hacia el mercado, es extremadamente importante trabajar permanentemente con un buen UX designer, dividiendo el concepto del producto en pequeñas partes, y, a lo largo del ciclo de desarrollo, añadir complejidad en el producto pero preservando siempre la consistencia lógica y funcional para el usuario.




Dejar una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.