¿Deben tener todas los sprints la misma duración?, ¿cuál es la duración óptima?

Es cierto que hay determinadas metodologías que recomiendan que los sprints tengan una duración que se encuentre comprendida en un intervalo de tiempo reducido. Estoy de acuerdo con ellas en que las iteraciones deben ser de corta duración, sobre esa base, mi visión personal es la siguiente:

– Cada proyecto se desarrolla en unas circunstancias y un contexto diferente. Una duración de sprint que resulta adecuada para uno puede no serlo para otro.

– Lo ideal podría ser aplicar sprints de duración fija pero en la realidad resulta complicado ajustarlo de esa manera ya que hay que tener en cuenta diversos factores: falta de disponibilidad en unas fechas concretas del product owner, la necesidad de tener un sprint algo más largo para incluir una funcionalidad esencial, la necesidad de un sprint más corto para solo incluir determinados ajustes, etc… No hay que cerrar las puertas, ni mucho menos a definir sprints de tamaño variable (eso sí, cada sprint tendrá su fecha de inicio y de fin que deberá ser respetada) por mucho que eso se considere poco ortodoxo en la teoría.

Sprints de corta duración permiten dar una rápida respuesta al cambio y obtener feedback cada poco tiempo, esa rápida respuesta no solo es consecuencia de que disminuya el tiempo necesario para llegar a producción sino también por el hecho de que se reduce tiempo de espera para trabajar sobre una funcionalidad no contemplada en el sprint (el tiempo de espera medio es la mitad de la duración de la iteración).

Ahora bien, sprints cortos requieren que el proceso de paso a producción sea rápido porque de lo contrario parte de las ventaja (sino toda) de las iteraciones cortas se quedan en nada. Esta situación no es posible en todas las organizaciones.

Sprints más largos se adaptan mejor a ese inconveniente y admiten más carga de trabajo (proporcional al tiempo).

Ambas soluciones tienen sus ventajas e inconvenientes pero podemos jugar con ellas en función de las necesidades que tenga el proyecto en cada momento, ya que no es ágil cerrarnos en banda a una duración determinada porque estaríamos priorizando la metodología a las necesidades del proyecto y del producto.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: