Cómo administrar la planificación de Sprint si las duraciones de Sprint cambian

Answer 1

Lo primero es lo primero. La mayoría de las metodologías de desarrollo ágil requieren que siempre se pueda enviar, excepto tal vez mientras se inicializa el proyecto. Por lo tanto, siempre debe tener disponible una versión demo de su producto. Su parte interesada debería poder ver una nueva demostración una vez cada iteración.

En Scrum, como señaló Cliff Gilley, su versión de demostración consta de los artefactos que se produjeron al final de la última iteración. Debe tener un mecanismo con el que pueda implementar fácilmente cualquier versión anterior o al menos la última versión de su solución de forma automática o de otro modo, de lo contrario, tal vez no sea lo suficientemente ‘ágil’. Una de las piedras angulares de cualquier metodología ágil es la retroalimentación constante. Lo que significa que debe tener una versión demo de su solución actualizada periódicamente, que se puede mostrar a las partes interesadas para obtener comentarios, preferiblemente por el propietario del producto cuyo trabajo es representar los intereses de las partes interesadas en el equipo scrum.

Ahora, si su parte interesada (especialmente si es alguien que puede desconectar su proyecto) no acepta ver la última versión estable y quiere ver lo que se hizo durante medio sprint, aquí están las cosas que puede señalar cortésmente

• Nunca se completa nada de valor en ‘medio sprint’, que en su caso son 5 días (sin contar los fines de semana) a menos que tenga muchas tareas ‘pequeñas’ que posiblemente pueda mostrar. Y si la parte interesada no está contenta con lo que se hizo en la última versión demostrable, entonces es poco probable que esté satisfecho con la mitad de un sprint de más trabajo, a menos que planee realmente estirar y trabajar realmente las noches y los fines de semana.
• Si la parte interesada no está contenta de ver la demostración de la última iteración y está listo para esperar media iteración para ver una demostración, entonces puede explorar y ver si puede esperar la mitad más para ver una demostración adecuada
• La razón por la que hay una iteración de 2 semanas es que les da a los desarrolladores tiempo para pensar y planificar adecuadamente su trabajo en un ritmo adecuado. Este ritmo es crítico, porque esto es lo que presta previsibilidad, sostenibilidad y capacidad de estimación al proyecto. Cambiar este ritmo con frecuencia distrae a los desarrolladores y afecta su previsibilidad.
• Si el interesado está firme y / o sus manos están atadas, entonces sugiero que no haga un Sprint para esa semana. Concéntrese solo en la demostración y haga que la demostración sea un éxito. Después de eso, puedes comenzar la próxima semana con un nuevo Sprint de 2 semanas. Aunque esto sigue siendo una distracción, no es tan malo si solo es una semana y eso también solo para una demostración. No hubiera recomendado esto si la duración del “vaquero” fuera más de una semana. También tenga en cuenta que esta es la última opción. Haga esto solo cuando haya agotado todas las opciones.

Answer 2

Los equipos pueden experimentar con diferentes duraciones de Sprint al comienzo de un proyecto. Se conforman con un valor y luego no lo cambian. Se sabe que la mayoría de los equipos se conforman durante 2 semanas. Tanto es así, que algunas organizaciones exigen una duración estándar de 2 semanas en todos los equipos. Es preocupante si esta duración cambia en el medio ya que perturba a los equipos de cadencia a los que se acostumbran.

Otro punto es mantener el producto siempre demostrable, como se señala en otras respuestas. Sin embargo, durante un Sprint, el producto no está listo para la demostración hasta que finalice.

Entonces, ¿cuáles podrían ser las posibles soluciones?

• Pídale a las partes interesadas que esperen a que termine el Sprint, cortésmente.
• Nuestro PO estaba muy integrado con el equipo. Por lo tanto, vería varias demostraciones durante la implementación de Sprint y reajuste para ajustarse a lo que quería. Esto fue bueno para nosotros, pero fue claro para todos que estas demostraciones intermedias también tendrían errores desconocidos. Si su parte interesada está de acuerdo con esta calidad, invítelo a su área de equipo y eche un vistazo a la demostración. Sin embargo, esto no será tan ceremonioso como una demostración regular de Sprint.
• Ya se sabe que la demostración ocurre una vez cada 2 semanas. Verifique si hubiera sido posible conocer con anticipación la intención de las partes interesadas de una demostración y planifíquela en el horario regular. Sin embargo, si se trata de una solicitud ad-hoc, la parte interesada debe ser educada sobre Agile y Scrum.
• Si tales solicitudes ad-hoc ocurren con frecuencia, es posible que deba verificar si la duración de Sprint es demasiado larga. Pero Scrum no recomienda una duración de Sprint menor a 2 semanas. Por lo tanto, debe introspectar si Scrum es el camino a seguir o si necesita un método ágil prescriptivo menor.
• Cancele este Sprint y trabaje hacia la demostración. Luego haga un análisis exhaustivo en la retrospectiva de Sprint para ver cómo se puede evitar que esto se repita.

Answer 3

Un aspecto clave de la planificación y definición del sprint es construir un ritmo constante al que el equipo se acostumbre a construir previsibilidad y un ritmo sostenible.

En este contexto, se recomienda encarecidamente que la duración del sprint no se cambie con frecuencia. De hecho, se recomienda mantener una longitud de sprint fija durante al menos 4 a 6 sprints.

Cambiar la duración / duración del sprint con frecuencia es muy perjudicial para un ritmo constante. Por lo tanto, es mejor fijar un calendario para el equipo del equipo que permita comentarios frecuentes y usar ese ritmo para mejorar continuamente.

Answer 4

La duración del sprint no debe ni puede cambiar sin la razón de que el equipo es tan maduro en la entrega continua que sienten que pueden desempeñarse mejor en sprints de una semana.

Si se necesita una demostración en medio del sprint, parece que las personas que lo solicitan también necesitan un poco de educación Scrum. Explíqueles por qué la demostración está al final del sprint.

En términos de planificación y estimación, lo único que cambia es la cantidad de puntos con los que puede comprometerse; y la intensidad del enfoque en la entrega. Tendría que aumentar una velocidad promedio durante al menos tres carreras cortas consecutivas. Esto guiará la planificación del sprint 4.

Inicialmente, si no tienes idea de la velocidad del equipo, necesitarían decirte cuándo sienten que tienen suficiente trabajo, que es la forma más natural para mí. SAFe dice que uno debería usar velocidad normalizada que no me gusta.

Answer 5

No se supone que los sprints o las iteraciones cambien en duración; se supone que son estáticos y predecibles, para que pueda predecir de manera confiable lo que el equipo podrá completar en el tiempo designado.

Si tiene una parte interesada que quiere una “demostración” a mitad del sprint, debe renegociar sus expectativas y pedirles que esperen hasta el final del sprint actual (momento en el que debería tener su demo de sprint programada regularmente), o debes planear un tiempo con ellos para mostrar lo que se completó en el último sprint, ya sea a través del Propietario del producto o como parte programada del sprint.

Answer 6

La planificación de Sprint es para el sprint actual, por lo que si te refieres a la longitud del Sprint que se cambia en el sprint actual, entonces sí, esa no es una buena práctica y debe evitarse.

Si está hablando de los cambios en la longitud del Sprint dentro del ciclo scrum, entonces eso es aceptable si los puntos de la historia tienen un alto valor comercial y necesitan más / menos tiempo, después de informar a los Propietarios de las Estacas.

¡Respondido!

Answer 7

La duración del sprint no debería cambiar espontáneamente. Al principio, el equipo puede experimentar con la duración, para verificar si, por ejemplo, un Sprint de 2 semanas es mejor que el Sprint de 1 semana. Pero una vez que se establece, se establece.

Si la duración cambia constantemente, no puede decidir el objetivo o las tareas que desea incluir . Esto significa que las estimaciones fallarán y que no será posible cumplir lo prometido.