Cómo estimar una historia de usuario utilizando una tabla de afinidad automatizada

Puntos de historia o días, o ambos?

Las personas a menudo discuten si usar puntos de historia o horas (o días) en la estimación de historias. Algunas personas creen que no necesitamos calcular puntos de historia ni velocidad del equipo en absoluto. Bueno, diferentes equipos pueden tener opiniones distintas, pero sin embargo, la mayoría de los proyectos Ágiles sí realizan la estimación de historias y la consideran como una de las herramientas muy útiles para llevar los proyectos a tiempo y dentro del presupuesto.

Tabla de afinidad para la estimación de historias

En Visual Paradigm, no consideramos la estimación de historias como un proceso conflictivo o de negociación, sino como un proceso de construcción de equipo que hace que la colaboración en tareas y la carga de trabajo sean claras y transparentes para todos en el equipo. La herramienta de historias de usuario empodera al equipo con la tabla de afinidad para automatizar el proceso de estimación de historias junto con la eliminación de los spikes. Además, la tabla visual de afinidad permite la estimación en tiempo real con puntos de historia y horas de historia al mismo tiempo. Cuando arrastras una historia a lo largo de la tabla, tanto el punto de historia como la hora se mostrarán simultáneamente mientras la historia sigue moviéndose. Simplemente suéltala en la cuadrícula donde tu equipo considere que la estimación es adecuada.

¿Cómo calcula la tabla de afinidad?

Para entender cómo se estiman automáticamente los puntos de historia y los días en la tabla de afinidad, debemos comprender que las cuadrículas horizontales representan el esfuerzo de trabajo, que aumenta de izquierda a derecha, y la complejidad del desarrollo de la historia (como nuevas tecnologías, nuevos dominios, etc.) aumenta de arriba hacia abajo.

Dado que el número máximo de días para desarrollar una historia de usuario debería ser no mayor que la duración del sprint (si no, la historia de usuario es demasiado grande y debe dividirse, o el sprint está establecido demasiado corto y requiere una extensión), el número de días de la cuadrícula inferior derecha también debería ser igual a la duración del sprint. Basándonos en esta suposición, la estimación de la historia puede calcularse automáticamente.

Afinidad de las historias de usuario para la estimación

La estimación de una historia de usuario nunca puede ser del 100 % precisa y, de hecho, ningún método puede lograrlo. Para mejorar la precisión de la estimación, comenzamos decidiendo la duración del sprint (por ejemplo, dos semanas o 10 días laborables) y realizamos la estimación en algunas historias de usuario con las que nos sentimos más cómodos (por ejemplo, 5 días y la certeza es media). En este caso, colocarás la historia en el centro verticalmente (nivel de certeza o riesgo) y horizontalmente (el esfuerzo de trabajo equivale a 5 días, o la mitad de la duración del sprint, que es de 10 días). A continuación, puedes usarla como punto de referencia para estimar las demás historias de usuario. Pregúntate si esta historia de usuario requiere más esfuerzo que la referencia, o menos, y si tiene más incertidumbre o menos. A medida que coloques más historias en la tabla de afinidad, podrás comparar varias historias para determinar si la distribución es lógica o no, y luego ajustarlas para que sean justas. El proceso es un poco más un arte que una ingeniería. Hazlo y discútelo en la reunión del equipo en lugar de cualquier confrontación. La precisión generalmente mejora a medida que el equipo se vuelve más maduro.

Elimina riesgos con el spike del proyecto

Según el Diccionario Ágil, la definición de Spike es:

“Una tarea orientada a responder una pregunta o recopilar información, más que a producir un producto entregable. A veces se genera una historia de usuario que no puede estimarse adecuadamente hasta que el equipo de desarrollo realice algún trabajo real para resolver una pregunta técnica o un problema de diseño. La solución consiste en crear un ‘spike’, que es algún trabajo cuyo propósito es proporcionar la respuesta o la solución.”

Al estimar una historia de usuario, no solo consideramos el esfuerzo de desarrollo, sino también los riesgos y las incertidumbres involucrados. Con frecuencia, se crea un spike antes del inicio formal de un sprint para gestionar el trabajo que debe realizarse para que otras historias de usuario puedan estimarse de forma justa.