El Sprint 1 comienza el 5 de noviembre y se supone que finaliza el 16 de noviembre, pero hay un feriado oficial del 13 al 15 de noviembre. ¿Puedo cambiar el horario del Sprint 1 para que sea del 5 de noviembre al 21 de noviembre?
Bart tiene razón, se supone que los Sprints tienen una duración fija y no varían de un sprint a otro. Si cambia constantemente las duraciones, no puede lograr una buena cadencia y esa es la clave para un Scrum efectivo.
Cuando tiene vacaciones en un sprint en lugar de extender el sprint, simplemente reconoce que no tiene tanta capacidad en este sprint. Tienes esto en cuenta cuando haces la planificación del sprint. Por ejemplo, si su velocidad promedio es 100 y tiene dos días de vacaciones en su sprint de diez días, entonces solo tiene el 80% de sus días. Entonces, multiplicarías tu velocidad por un 80% para una capacidad de sprint de 80 puntos.
La única área en la que los días festivos causan problemas es si el Sprint comienza o finaliza en un día festivo. Si lo hacen, simplemente mueva los eventos apropiados a otro día sin cambiar la duración del sprint.
Las vacaciones son una de las principales razones por las que muchos entrenadores, incluido yo mismo, recomendamos comenzar los Sprints los jueves o miércoles. La mayoría de los días festivos caen en lunes o viernes, por lo que limita las posibilidades de que sus eventos principales caigan en un día festivo.
Se recomienda mucho tener una duración constante para sus sprints y tener las principales ceremonias (planificación de sprint, revisión de sprint, retrospectiva) cada vez el mismo día de la semana.
Esto crea un ritmo fácilmente predecible para los sprints y hace que sea fácil de recordar para todos cuando necesitan estar disponibles para esas ceremonias.
La única razón para mover el inicio/fin del sprint a una fecha diferente debe ser que la fecha normal es un día en el que la mayoría de los participantes no está disponible (festivo nacional, empresa cerrada, etc.).
Las vacaciones que caen dentro del sprint se deben contabilizar con una menor disponibilidad del equipo de desarrollo (y, como resultado, menos trabajo previsto/planificado para terminar).
En Scrum, una cadencia confiable siempre es más importante que un nivel fijo de productividad. Scrum se trata realmente de una entrega sostenible a lo largo del tiempo, por lo que manejar las perturbaciones en la capacidad es una característica del marco.
Se esperan feriados, vacaciones, días de enfermedad y terminaciones anticipadas en cualquier proyecto de larga duración. Estos pueden y deben manejarse como variaciones menores en la capacidad del equipo en lugar de como cosas que pueden descarrilar la cadencia continua del proyecto.
Por ejemplo, el Sprint 1 es el 5 de noviembre y se supone que finaliza el 16 de noviembre, pero nuestro gobierno anunció que serán feriados los días 13, 14 y 15 de noviembre, ¿puedo cambiar el cronograma del Sprint del 5 al 21 de noviembre?
Tener Sprints de 12 días es extraño, pero ciertamente permitido. Si tiene un feriado de tres días dentro del Sprint, entonces no debe cambiar la duración del Sprint (porque un Sprint debe tener una duración de calendario de tamaño constante). Sin embargo, ciertamente debe reducir su capacidad esperada para el Sprint para tener en cuenta los tres días hábiles menos que tendrá para producir trabajo dentro del Sprint. Por lo general, esto se realiza durante la planificación del Sprint para que se maneje de manera adecuada a lo largo del Sprint.
Dado que el primer o último día de su Sprint no es feriado, debe mantener su Revisión y Retrospectiva del Sprint en el día estándar de finalización del Sprint, el 16 de noviembre. Sin embargo, ciertamente puede cambiar otras ceremonias, como el refinamiento de la acumulación dentro del Sprint, para adaptarse a las vacaciones si es necesario.
En el caso de que un feriado afecte el final de su Sprint (no es el caso aquí, pero sucede), generalmente debe:
En general, unas vacaciones durante un Sprint obviamente afectarán la cantidad de trabajo que se puede realizar dentro del Sprint, pero no es necesario que tenga un impacto importante en el ciclo de las casillas de tiempo. La mejor práctica es encapsular cualquier desviación dentro del cuadro de tiempo actual. Eso significa mover las ceremonias dentro del Sprint actual siempre que sea posible, en lugar de extender el Sprint o mover las ceremonias o el trabajo a un cuadro de tiempo posterior.
Como señaló Joel en una respuesta separada, es aconsejable programar Sprints para evitar días festivos comunes. Sin embargo, eso no siempre es posible, así que simplemente trate los días festivos como una capacidad reducida de la misma manera que trataría a los miembros del equipo cuando están enfermos.
Siempre que reduzca los pronósticos para reducir el trabajo planificado para la iteración, si mueve las ceremonias dentro o fuera del cuadro de tiempo es una compensación. En el primer caso, simplemente está haciendo transparente el impacto de las vacaciones en su proceso; en el último caso, está impactando dos Sprints, pero posiblemente distribuyendo el costo del trabajo perdido como una capacidad ligeramente reducida en dos Sprints en lugar de uno. Ciertamente recomiendo lo primero, pero los equipos pueden (y a veces lo hacen) argumentar a favor de lo segundo si se hace con transparencia y aceptación en toda la organización.
La cantidad de trabajo realizado dentro de un Sprint no es un valor constante. Sin embargo, el cuadro de tiempo debe ser lo más constante posible. Durante un proyecto largo, es mucho mejor tener Sprints de baja capacidad o acortados debido a vacaciones, miembros del equipo enfermos o terminaciones anticipadas que comienzan y terminan los mismos días cada Sprint porque eso respalda la programación a largo plazo y la planificación de lanzamientos mejor que con frecuencia. moviendo las ceremonias alrededor.
Seguir este consejo puede dar como resultado Sprints con una capacidad significativamente reducida, o Sprints ocasionales con holgura excesiva o incluso "aire muerto". Sin embargo, en general, el valor de una cadencia de iteración confiable supera con creces el cambio ocasional en la capacidad o la productividad, y contener la variación dentro de un solo Sprint hace que esta variación sea visible y transparente para todas las partes interesadas.
La Guía Scrum dedica dos oraciones completas al tema de los Sprints no estándar:
Los sprints tienen duraciones constantes a lo largo de un esfuerzo de desarrollo. Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.
Uno se ve obligado a leer esto un poco. Pragmáticamente, "duración" se refiere a la duración del calendario, no a los días laborables ni a los días a plena capacidad, porque de lo contrario no podría haber una cadencia fiable para usar en la planificación de la liberación. El consejo de comenzar un Sprint nuevo inmediatamente después del Sprint anterior se basa en iteraciones estándar; la guía no dice nada sobre el tema de si iniciar un Sprint reducido inmediatamente después de un Sprint abortado, si permitir el "aire muerto" o el servicio de la deuda tecnológica hasta que comience el próximo Sprint, o cómo manejar las vacaciones o los cambios imprevistos en el personal disponible.
Las personas que quieran apelar a la autoridad en este tema se irán con las manos vacías. Las mejores soluciones para este tipo de problemas son una mezcla de:
Mientras no viole los principios básicos del marco, todo lo que haga que sea exitoso para el equipo es, ipso facto , lo correcto. Por lo tanto, su kilometraje variará.
Sí , se pueden incluir días festivos. Pero el Cliente/Cliente debe ser informado sobre las vacaciones con anterioridad.
Los sprints pueden tener una duración variable, aunque recomendaría tratar de mantener la duración del sprint lo más constante posible.
Entonces, sí, puede programar el sprint para que sea tan largo como lo considere oportuno, pero no lo cambiaría todo el tiempo.
La respuesta corta es no. Debería poder conocer estas vacaciones con anticipación y ajustar la acumulación de sprint en consecuencia durante la planificación del sprint. Si su velocidad promedio es X, puede ajustarla a X - (Y * número de vacaciones), donde Y es su velocidad diaria promedio. No puede cambiar las fechas de los sprints debido a vacaciones, a alguien que se enferme o cualquier otra cosa. Si no se puede entregar una gran parte del trabajo comprometido, informe al propietario del producto y estoy seguro de que las partes interesadas lo entenderán durante la reunión de revisión del sprint. ¡No consigues nada cambiando la duración del sprint! Al extender la longitud, crea confusión (especialmente en configuraciones a gran escala) y complica los cálculos de velocidad, entre otras cosas.
Todd A. Jacobs
Mahoma