La estimación de historias se basa en la noción de que, con el tiempo, un equipo gana experiencia para resolverlas. Con ello se mejora la precisión y se puede establecer la velocidad para medir la velocidad de un equipo. Una metodología perfecta para establecer pronósticos confiables para futuros esprints.
Los errores son un hecho de la vida de una empresa de desarrollo de software. Si bien estoy de acuerdo en que todos los errores deben detectarse durante el desarrollo de una historia, aceptar que esto no se puede lograr en todo momento, debería ser algo que todos los equipos deben planificar. En lugar de pensar obstinadamente que el proceso debe gobernar al equipo, debe ser al revés.
Por supuesto, error o historia, desde el punto de vista comercial, no importa con qué esté tratando el equipo. Ambos pueden producir una cantidad igual de valor para el propietario del producto.
En nuestro equipo, hemos experimentado con algunas técnicas para estimar errores:
- Estimación de errores completamente desconocidos
- Solo estimando errores que ya fueron analizados
- Asignar tiempo para corregir errores y no estimar errores, en lugar de eso, clasifíquelos únicamente en función del valor comercial
Con 1. hemos fallado de manera lamentable. Para la mayoría de los errores, hemos encontrado que el 90% del tiempo se invierte en el análisis de errores. Después de eso, la corrección de errores se puede estimar de la misma manera que una historia. Al planear los errores en un sprint, cometimos el error de que el alcance desconocido afectó la resolución de la historia hasta el punto donde casi todos los sprint que hicimos de esta manera fallaron.
Según la opción 2 de la técnica de estimación de la relación 90/10 (corrección de corrección de errores), esto significaba que teníamos que planificar un análisis que no estaba cubierto por la planificación del sprint (habíamos aprendido de la opción 1, pero No hay una solución real de cómo seguir con los errores analizados). El resultado fue que el análisis de errores no se realizó porque un sprint se centró en los elementos planificados. El equipo no tuvo tiempo de centrarse en los errores de la cartera. Así que eventualmente tampoco se hicieron.
Al aceptar la incertidumbre, ahora nos hemos decidido por la opción 3. Hemos dividido la cartera de productos en una parte de la historia / tarea regular que el equipo puede estimar utilizando puntos de historia y una cartera de errores. En la acumulación de errores, el propietario del producto clasifica los errores según el valor comercial y el criterio del equipo muy aproximado. El equipo permite asignar una parte del tiempo durante un sprint que puede dedicar a centrarse en los errores. El propietario del producto no conoce el resultado exacto, ya que antes no era posible planearlo. La proporción de la acumulación de errores en comparación con la acumulación regular se puede ajustar para cada sprint dependiendo del estado actual de cada acumulación y la importancia y el valor comercial del contenido.
Al eliminar la incertidumbre, liberó al equipo nuevamente. Sprints no fueron comprometidos por errores desconocidos. Al separar los errores en una acumulación diferente, tanto el enfoque del sprint habitual del equipo aumentó como los que nos permitieron terminar con los errores que también tenían un valor comercial significativo.
Depende de si los puntos de la historia son adecuados para ti. Intentaría estimar errores utilizando puntos de historia primero. Si eso no funciona, pruebe mi opción 3. Ha hecho que nuestro (más de 30 sprint de edad) se centre nuevamente en errores antiguos que contienen un gran valor comercial. También nos ha liberado de intentar entregar algo que el equipo simplemente no puede estimar. La aceptación de lo desconocido nos acercó más a la realidad y también hizo que nuestros sprints volvieran a ser exitosos mientras ofrecía una gran parte (basada en la relación error-historia) de valor comercial a través de la corrección de errores. La relación que usamos recientemente fue de 50/50.