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
Buscar temas

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 la gestión de productos quiere hacer algo que parece sencillo, como admitir un nuevo navegador web, el desarrollo y el control de calidad deben dar su opinión también, ya que su experiencia les ha enseñado qué dragones pueden estar al acecho bajo la superficie.

Asimismo, los cambios de diseño requieren no sólo la aportación del equipo de diseño, sino también la del de desarrollo y la del de QA. Dejar a parte del equipo de 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 a lo Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Puede parecer antintuitivo, pero esa abstracción es útil porque incita al equipo a tomar decisiones más difíciles acerca de la dificultad del trabajo. Estas son algunas pocas razones para usar puntos de historia:

  • Las fechas no tienen en cuenta el trabajo no relacionado con el proyecto 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 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, como es 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 entregar valor, no en el tiempo dedicado. 

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 en 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.

Para los elementos que se encuentren más abajo en el 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 estimaciones no serán tan precisas. No pierdas tiempo estimando trabajo que posiblemente cambiará. 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 comparar las cinco últimas historias de usuario que haya entregado el equipo con un valor de 8 puntos de historia. Estudia si cada uno de estos elementos de trabajo tuvo un nivel de esfuerzo similar. Si no, analizad por qué. Utilizad esta información 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