Puntos de historia y estimación

Una buena estimación ayuda a los propietarios de los productos a optimizar sus procesos en términos de eficiencia e impacto. Por eso es tan importante.

Dan Radigan Dan Radigan
Browse topics

La estimación es complicada. Para los desarrolladores de software, es uno de los aspectos más difíciles de su trabajo, por no decir el más difícil. Conlleva tener en cuenta un montón de factores que ayudan a los propietarios de los productos a tomar decisiones que afectan a todo el equipo, así como a la empresa. Con todo eso en juego, no es de extrañar que todos, desde los desarrolladores hasta la alta dirección, tiendan a perder los estribos sobre este tema. Craso error. La estimación en la metodología ágil no es más que eso, un cálculo: no es un juramento de sangre.

No es obligatorio trabajar los fines de semana para compensar el tiempo de más que nos lleva un trabajo que habíamos subestimado. Dicho eso, veamos algunas maneras de realizar estimaciones con la mayor precisión posible.

Colaboración con el propietario del producto

En un desarrollo ágil, el propietario del producto se encarga de priorizar el backlog, es decir, la lista ordenada de trabajo que contiene descripciones breves de todas las funciones y correcciones de un producto. Los propietarios del producto capturan los requisitos de la empresa, pero no siempre entienden los detalles de la implementación. Por ello, una buena estimación puede informar al propietario del producto sobre el nivel de esfuerzo de cada elemento de trabajo, que a su vez sirve para evaluar la prioridad relativa de cada elemento.

Cuando el equipo de ingeniería empieza su proceso de estimación, normalmente surgen preguntas sobre los requisitos y las historias de usuario. Esto es algo positivo: las preguntas ayudan a todo el equipo a entender el trabajo mejor. Específicamente en el caso de los propietarios de los productos, la división granular de los elementos de trabajo y las estimaciones les ayudan a priorizar todas las áreas del trabajo, incluidas las que pueden estar ocultas. Con las estimaciones del equipo de desarrollo en la mano, no es extraño que un propietario del producto reordene los elementos del backlog.

La estimación ágil es un trabajo en equipo

Involucrar a todo el mundo (desarrolladores, diseñadores, testers, deployers... todos) en el equipo es clave. Cada miembro del equipo aporta una perspectiva diferente sobre el producto y el trabajo necesario para entregar una historia de usuario. Por ejemplo, si el departamento de gestión de productos quiere hacer algo que parece sencillo, como admitir un nuevo navegador web, se debe tener el cuenta la opinión de los trabajadores de desarrollo y control de calidad, ya que su experiencia es fundamental para determinar con qué dificultades se pueden encontrar.

Asimismo, los cambios de diseño requieren no solo la aportación del equipo de diseño, sino también la de los equipos de desarrollo y de control de calidad. Dejar a parte del equipo del producto más amplio fuera del proceso de estimación crea estimaciones de menor calidad, baja la moral porque los contribuyentes clave no se sienten incluidos y compromete la calidad del software.

No dejes que tu equipo sea víctima de las estimaciones poco precisas. Es un camino seguro al fracaso.

Puntos de historia frente a horas

Los equipos de software tradicionales dan estimaciones en un formato de tiempo: días, semanas, meses, etc. Muchos equipos ágiles, sin embargo, ahora usan los puntos de historia. Los puntos de historia evalúan el esfuerzo relativo del trabajo en un formato basado en la sucesión de Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Puede parecer poco intuitivo, pero esa abstracción es útil porque incita al equipo a tomar decisiones más difíciles acerca de la dificultad del trabajo. A continuación te presentamos algunas razones por las que es una buena idea usar los puntos de historia:

  • Las fechas no tienen en cuenta el trabajo no relacionado con los proyectos que inevitablemente surge en nuestro día a día, como correos electrónicos, reuniones y entrevistas en las que un miembro del equipo puede tener que participar.
  • Las fechas tienen una connotación emocional. La estimación relativa elimina este componente.
  • Cada equipo estima el trabajo en una escala ligeramente diferente, lo cual significa que su velocidad (medida en puntos) será diferente de manera natural. Asimismo, esto imposibilita que se politiquee usando la velocidad como arma.
  • Una vez que se llegue a un acuerdo sobre el esfuerzo relativo del valor de cada punto de historia, podrás asignar puntos rápidamente sin que haya lugar a demasiado debate. 
  • Los puntos de historia recompensan a los miembros del equipo por resolver incidencias basándose en la dificultad, y no en el tiempo empleado. De esta forma, los miembros del equipo se mantienen centrados en el valor de la entrega, no en dedicarle tiempo. 

Puntos de historia y póker de planificación

Los equipos que se estén iniciando en los puntos de historia usan un ejercicio llamado póker de planificación. En Atlassian, el póker de planificación es una práctica habitual en toda la empresa. Los miembros del equipo toman un elemento del backlog, hablan sobre él brevemente y cada uno fórmula mentalmente una estimación. A continuación, todos levantan una tarjeta con el número que refleje su estimación. Si todo el mundo está de acuerdo, ¡estupendo! De lo contrario, dedica algo de tiempo (no mucho, tan solo un par de minutos) para entender el motivo detrás de las distintas estimaciones. Recuerda, sin embargo, que la estimación debe ser una actividad de alto nivel. Si el equipo se va por las ramas, respira hondo y encauza el debate a un nivel más general.

¿Listo para intentarlo? 

Estima con mayor inteligencia, no con mayor esfuerzo

Ninguna tarea individual debe superar las 16 horas de trabajo. (Si usas puntos de historia, puedes decidir que 20 puntos es el límite superior, por ejemplo). Sencillamente, es demasiado complicado estimar elementos de trabajo individuales de mayor duración con confianza. Esa confianza es especialmente importante para los elementos de la parte superior del backlog. Cuando algo se estima por encima del límite de 16 horas (o 20 puntos) del equipo, será una señal para dividirlo granularmente y volver a estimarlo.

En el caso de los elementos que se encuentran al fondo del backlog, basta con una estimación aproximada. Cuando el equipo empiece a trabajar en esos elementos, los requisitos podrían haber cambiado y la aplicación seguramente habrá cambiado también, de modo que las primeras estimaciones no serán tan precisas. No pierdas tiempo estimando trabajo que posiblemente cambie. Da al propietario del producto una cifra aproximada que pueda utilizar para priorizar la hoja de ruta del producto adecuadamente.

Aprende de las estimaciones anteriores

Las retrospectivas constituyen un momento para que el equipo incorpore ideas de iteraciones anteriores, incluida la precisión de sus estimaciones. Hay muchas herramientas ágiles (como Jira Software) que realizan el seguimiento de los puntos de historia, cosa que facilita en gran medida el análisis y el recalibrado de las estimaciones. Prueba, por ejemplo, a analizar las cinco últimas historias de usuario que haya entregado el equipo con un valor de puntos de historia de 8. Comentad si cada uno de estos elementos de trabajo tuvo un nivel de esfuerzo similar. Si no, analizad por qué. Utilizad ese concepto en los siguientes debates de estimaciones.

Al igual que el resto de los aspectos de un proceso ágil, la estimación es una cuestión de práctica. Irás mejorando con el tiempo.

A continuación
Metrics