¿Quién determina la duración del Sprint?

Foto de Sohrab Salimi
Sohrab Salimi
3 min. tiempo de lectura
Este contenido fue traducido con IA. Ver original

Una consideración importante en un equipo Scrum es cuánto deben durar los Sprints. Si son demasiado largos, pueden ocurrir demasiadas variaciones. Si son demasiado cortos, un equipo podría no terminar trabajos importantes o tener que reducir su Definition of Done para completar los trabajos.

¿Quién decide la duración del Sprint?

Por supuesto, la respuesta es: todo el equipo. Y eso incluye al Scrum Master, al Product Owner y a los miembros del equipo (programadores, testers, diseñadores, etc.).

Pero, ¿qué sucede cuando estas muchas personas no logran ponerse de acuerdo?

¿Discutirán hasta el fin de los tiempos hasta que finalmente tomen una decisión común?
No. En última instancia, es el Scrum Master quien puede determinar la duración de un Sprint.

El Scrum Master tiene la última palabra sobre la duración del Sprint

Un buen Scrum Master hará todo lo posible para encontrar una solución común. Pero si ha agotado todas sus posibilidades y aún no se vislumbra un acuerdo, debe tomar una decisión.

Esto no debería ocurrir con demasiada frecuencia. Espero que la mayoría de los Scrum Masters nunca tengan que decir: "He escuchado todas las opiniones, pero lo haremos como yo digo." Sin embargo, dado que el Scrum Master es responsable del proceso dentro del equipo, también le corresponde la decisión final.

Un ejemplo de por qué una duración corta de Sprint es buena

Una vez asesoré a un equipo que trabajaba con Sprints de cuatro semanas. Los miembros del equipo tenían dificultades para incluir la cantidad correcta de trabajo en sus Sprints. En los seis meses antes de que yo llegara al equipo, en cada Sprint se descartaba aproximadamente un tercio del trabajo.
Era un buen equipo que realizaba trabajo de primera clase. Los miembros del equipo simplemente no sabían cuánto podían lograr en cuatro semanas. Su optimismo los llevaba a dar constantemente compromisos demasiado altos.

Pedí al equipo que pensara en una solución al problema y que me comunicara los resultados al día siguiente. Me alegré cuando al día siguiente me dijeron que definitivamente había que cambiar la duración de los Sprints. “Sí”, dije, “¡por supuesto!”

Los miembros del equipo se sintieron aliviados por mi aprobación y dijeron:

“¡Wow! ¡No pensábamos que nos permitirías Sprints de seis semanas!”

Tuve que informarles que, si bien estaba de acuerdo en cambiar la duración del Sprint, era mejor acortarla en lugar de alargarla.

Finalmente hicimos lo que yo – como Scrum Master consultor – había sugerido y acortamos la duración del Sprint.

¿Por qué debería el Scrum Master determinar la duración del Sprint?

El equipo ya empaquetaba trabajo para seis semanas en un Sprint de cuatro semanas. Si el equipo tuviera Sprints de seis semanas, seguramente metería ocho o nueve semanas de trabajo en ellos.

Así que los miembros del equipo tenían que aprender cuánto trabajo cabe en un Sprint (sin importar su duración). Como Scrum Master contratado como consultor, yo podía reconocer todo eso más fácilmente que ellos mismos.

Quiero recalcar una vez más que esto solo debería hacerse en situaciones excepcionales. Puedo contar con los dedos de una mano las veces que tomé una decisión así después de que un equipo no lograra ponerse de acuerdo. Pasar por encima de un equipo en algo tan importante como la duración de un Sprint solo debería hacerse con mucha precaución. Pero al fin y al cabo se trata del cumplimiento del proceso y eso es responsabilidad del Scrum Master.

Este texto proviene del blog de Mike Cohn y fue traducido por nosotros al alemán.

Habla con nuestro Asistente Habla con nuestro Asistente