Estimación de historias de usuario – Tabla de afinidad

Cómo estimar historias de usuario para el desarrollo ágil

Estimar una historia de usuario es difícil. ¿Cómo podemos obtener la mejor estimación del tamaño de una historia? Algunas personas dicen que el mejor tamaño debe estimarse en puntos de historia, y otros prefieren que se estimen en horas o días.

Bueno, estimar definitivamente es difícil, pero hay algunos conceptos que pueden ayudarnos en el proceso de estimación de historias de usuario:

1. Estime las historias de usuario en términos relativos desde dos aspectos
   • Esfuerzo de trabajo
   • Riesgo (por ejemplo, complejidad e incertidumbre)
2. Estime las historias de usuario usando puntos de historia
3. Coloque esas historias de usuario en la tabla de afinidad en las que tenga mayor confianza en la estimación en términos de esfuerzo de trabajo y complejidad (riesgo)
4. Estime gradualmente las otras historias de usuario menos familiares en términos de esfuerzo de trabajo y complejidad comparándolas con aquellas historias que ya han sido estimadas en la tabla de afinidad.

Afinidad de historias de usuario para la estimación

La estimación de una historia de usuario nunca puede ser del 100 por ciento 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 hábiles) y realizamos la estimación en unas cuantashistorias de usuariocon las que nos sentimos más cómodos en términos de estimación (por ejemplo, 5 días y la certeza es media). En este caso, colocará la historia en el centro verticalmente (certeza oriesgonivel) y horizontalmente (esfuerzo de trabajoesfuerzoes igual a 5 días, o la mitad de la duración del sprint, que es de 10 días). Entonces puede usarlo como punto de referencia para estimar las otras historias de usuario. Pregúntese si esta historia de usuario requiere más esfuerzo que la referida, o menos, y si tiene más incertidumbre o menos. A medida que coloque más historias de usuario en la tabla de afinidad, puede comparar varias historias para determinar si la distribución es lógica o no, y luego ajustarlas para que sean justas, y eso es todo. El proceso es un poco más un arte que una ingeniería. Hágalo y discútalo 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.

¿Cómo calcula la tabla de afinidad? (Ver un video) 

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 (por ejemplo, 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 más que la duración delsprint (si no, ya sea que la historia de usuario sea demasiado grande y necesite dividirse, o que el sprint esté demasiado corto y requiera una extensión), por lo tanto, el número de días de la cuadrícula inferior derecha también debería ser igual a la duración del sprint. Basado en esta suposición, la estimación de la historia puede calcularse automáticamente.

Observe que: En el primer ejemplo anterior

Puntos de historia = Esfuerzo x Riesgo (por ejemplo, 3 x 4 = 12)

Unidad de puntos de historia = Número total de puntos / Duración del sprint (por ejemplo, 100 / 20) = 0.2

Días (horas) de historia = Puntos de historia / Unidad de puntos de historia (por ejemplo, 12 x 0.2) = 2.4

Elimine los 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 entregableproducto. 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”

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

Descarga y pruébalo ahora!