Planificación de Sprint: Pronóstico vs Compromiso
Encontré una discusión interesante sobre el tema anterior:
En el verano de 2011, Ken Schwaber y Jeff Sutherland revisaron su Guía Scrum . En él, eliminaron un comportamiento establecido desde hace mucho tiempo conocido por Scrum, que es el compromiso que el equipo hace con el propietario del producto y los clientes. Compromiso fue reemplazado por pronóstico . Dicen que los equipos pueden prever su trabajo, pero no comprometerse con él.
El autor: Mitch Lacey abordó su opinión que extraje del artículo de la siguiente manera:
Si bien entiendo su lógica, prefiero el compromiso por las siguientes razones:
- Comprometerse con algo pone al equipo en una mentalidad diferente a la de solo pronosticar. Si un equipo pronostica, se da a entender que no cumplir con todo lo que dijo que podía hacer es un comportamiento aceptable. Si bien los equipos pueden aprender de sus pronósticos y eventualmente tener menos variación de estimación , encuentro que los equipos que pronostican tardan más en reducir la variación en comparación con los equipos que se comprometen .
- Pronosticar, o estimar, es apropiado para la acumulación de productos . Sin embargo, cuando los equipos mueven historias de la cartera de productos a la cartera de sprints y las desglosan, están agregando otro nivel de granularidad, descubriendo pequeños detalles que les permiten preguntarse » ¿podemos comprometernos con esto?» La previsión corre el riesgo de volver a caer en un estado perezoso por parte del equipo, en lugar de decir «solo necesitamos pronosticar, está bien si nos perdemos algunas cosas, podemos resolverlo todo más tarde».
¿ Qué dice Scrum.org sobre «Pronóstico» o «Compromiso»?
Hay una razón inmediata para el cambio, que tiene que ver con el significado de las palabras mismas. La palabra compromiso generalmente se relaciona con los deberes asumidos. Después de comprometerse a entregar una lista de elementos de la cartera de productos, el equipo Scrum , principalmente el propietario del producto y especialmente las partes interesadas, pueden sentir que existe la obligación de entregarlos todos al final del Sprint. Pero la realidad nos sigue demostrando que es difícil, si no imposible, cumplir siempre con este compromiso autoimpuesto sin comprometer la calidad. Una acumulación de Sprint es lo suficientemente complejo como para que la incertidumbre esté siempre presente, y el sentido común nos dice que no debemos prometer lo que no estamos seguros de poder cumplir. Cuando usamos la palabra comprometerse, podemos estar sesgados fácilmente hacia esa forma de pensar deber-obligación-promesa.
Mi opinión personal:
Creo que ambos lados tienen la lógica sólida detrás. ¿Cuál es su comentario y opinión?