Los puntos de historia no son útiles para estimar el esfuerzo del trabajo del Sprint para construir el incremento

Los puntos de historia no son útiles para estimar el esfuerzo de del trabajo del Sprint para construir el incremento

Si bien es cierto los puntos de historia pueden ayudar a realizar una proyección del Product Backlog o referenciar una complejidad al definir un dimensionamiento de sus elementos, solamente los puntos de historia no serían tan útiles para determinar el trabajo de construcción del producto que se requiere, como por ejemplo, la codificación, pruebas, dependencias técnicas, entre otros tipos, ya que no contiene información referente a estos aspectos, es por esta razón que no es tan determinante para definir el esfuerzo del trabajo para lograr un incremento terminado en el Sprint.

Algunas recomendaciones para realizar la estimación del esfuerzo de construcción del Sprint son las siguientes:

1. Mejorar la definición de los criterios de terminado para que definan de una mejor manera el trabajo necesario para tener un incremento de producto terminado potencialmente liberable al mercado y en base a esto los desarrolladores puedan estimar el trabajo necesario para construir.
2. Facilitar la discusión sobre los aspectos técnicos de las dependencias, impedimentos y otros que puedan representar un riesgo para construir el producto.
3. Evitar usar la velocidad los puntos de historia como “capacidad” del equipo de tal manera que defina lo que el equipo debe lograr en cantidades límites de puntos de historia, porque esto reduce la autogestión, creatividad y la búsqueda de soluciones en equipo para entregar incremento de producto.
4. Incluir los requerimientos no funcionales como seguridad, infraestructura, etc. en el Product Backlog y los criterios de terminado para facilitar la discusión sobre lo que se necesita para tener un producto listo para lanzarse a producción.
5. Elaborar un flujo del proceso de desarrollo, que puede ser visualizado en un tablero Kanban, para representar de manera visual el impacto de los criterios de terminado y de esa manera mejorar la estimación del pronóstico del Sprint.
6. Usar “spikes” o pruebas de concepto cuando sea necesario para mejorar el entendimiento de los elementos del Product Backlog que ayude a realizar una estimación del esfuerzo.
7. Evitar mucha discusión en ponerse de acuerdo en los puntos de historia por cada elemento del Product Backlog, en lugar de eso discutir sobre los criterios de terminado y la manera de lograr implementarlos en el producto.
8. Reducir el uso de la velocidad promedio en puntos de historia para hacer proyecciones, en lugar de eso tomar en cuenta la variabilidad el flujo en Kanban y usar métodos que brinden información en base a probabilidades, que se adaptan mejor a entornos empíricos con incertidumbre.