Hacer estimaciones es complicado. 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 ágil de los puntos de historia no es más que eso, un cálculo: no es un pacto 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 empresariales, 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 de los puntos de historia 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.
¿Quieres probar los puntos de historia? En primer lugar, regístrate o inicia sesión en Jira
Puntos de historia frente a horas
Los equipos de software tradicionales proporcionan estimaciones en un formato de tiempo concreto: pueden ser días, semanas o meses. Sin embargo, muchos equipos ágiles han decidido pasarse a los puntos de historia. Se trata de unidades de medida que permiten expresar una estimación del esfuerzo total que deberá hacer el equipo para implementar íntegramente un elemento del backlog del producto o cualquier otro trabajo. Los equipos asignan puntos de historia en función de la complejidad y del volumen del trabajo, así como del riesgo o de la incertidumbre. Los valores se asignan para desglosar el trabajo de forma más eficaz en partes más pequeñas. De esta manera, se puede gestionar la incertidumbre. Con el tiempo, esto ayuda a los equipos a ser conscientes de lo que pueden llegar a conseguir en un período de tiempo concreto y genera un sentimiento de consenso y compromiso con la solución. Aunque pueda parecer contradictorio, esta abstracción es realmente útil, ya que obliga al equipo a tomar decisiones más complejas sobre la dificultad del trabajo. A continuación, se indican algunos motivos por los cuales es recomendable utilizar 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.
Lamentablemente, los puntos de historia se suelen utilizar de forma incorrecta; por ejemplo, cuando se emplean para juzgar a las personas o para asignar cronogramas y recursos detallados, o bien cuando se confunden con una medida de productividad. La auténtica función de los puntos de historia es que los equipos puedan hacerse una idea del volumen de trabajo y saber qué partes tienen prioridad. Para ver un debate en profundidad sobre los puntos de historia y las prácticas relacionadas con las estimaciones, échale un vistazo a esta mesa redonda con expertos del sector. Si quieres más consejos sobre la estimación ágil, sigue leyendo.
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 Planning Poker. En Atlassian, el Planning Poker 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 de las distintas estimaciones. Recuerda, sin embargo, que la estimación debe ser una actividad bastante general. Si el equipo se va por las ramas, respira hondo y deriva el debate a un superior.
¿Listo para intentarlo?
- Instala esta Aplicación de póker de planificación
- Obtén más información sobre el póker de planificación
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 de metodología ágil (como Jira) que hacen el seguimiento de los puntos de historia, lo cual 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. Determinad 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.
Recursos relacionados
