Planificación de Sprint: Pronóstico vs Compromiso

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?

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.