Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad

Hola a todos
Muchas veces veo a los equipos, scrum masters y product owners enfrascados en discusiones sobre la puntuación de los ítemes de backlog y la forma de obtenerla, este no debe ser el foco (desde mi punto de vista)

Pongamos las cosas claras, según la guía lo más importante del sprint planning es definir el objetivo que se quiere lograr (o la capacidad de negocio que vamos a proporcionar con el trabajo de esas máximo 4 semanas - prefiero pensar que son 2 semanas, que es un tamaño más sano de sprint - ), en segundo lugar tenemos:

• qué vamos a hacer
• cómo lo vamos a hacer

Ese ¿qué? tiene como entrada clave la pregunta

¿que capacidad tenemos?,

basado en esta pregunta el equipo determinará a cuantos ítemes de backlog se compromenten.

Si los ítemes de backlog (historias de usuario, casos de uso, requisitos en prossa o lo que sea) se estiman en:

• Días productivos (un punto = 1 dia productivo)
• basados en una funcionalidad pivote ( 1 punto = la construcción de una funcionalidad pequeña que agrega valor)
• basado en cantidad de historias de usuario (´por ejemplo: somos capaces con 6 historias de usuario en promedio por sprint)
• en ojo de buen cubero (creemos que somos capaces de hacer esta cantidad de historias, por que una vocecita interior nos lo dice), o
• en Garrapatandamandapispuntos, donde un Garrapatandamandapispunto equivale a 3 escaramanditabitas

Es perfecto, pues llega un momento donde el equipo dice (independiente del método que elijan):

!No más¡, creemos que somos capaces de hacer hasta acá en este sprint.

Se que es dificil soltar nuestro afán de medir, pero dada la incertidumbre que tiene asociado el software ¿qué ganamos con ser más precisos?, ¿gastar más tiempo en estimaciones que igual van a fracasar?

Hasta acá esta pequeña reflexión

Saludos Ágiles
Jorge Abad