Intentábamos determinar la longitud óptima del sprint para nuestro proyecto. Después de trabajar durante 3 semanas, pensamos que cortar el sprint a 2 semanas proporcionaría una mejor velocidad.
Las ventajas eran claras: un ciclo de retroalimentación más corto, pequeñas historias (con valor para el usuario), etc. Por otro lado, hay muchas desventajas, como las ceremonias (planificación, retrospectiva), etc., en las que no producimos y ahora suceden con más frecuencia.
Me preguntaba cómo, para un nuevo equipo, ¿podemos decidir la longitud óptima del sprint?
Respuestas:
Creo que lo estás mirando un poco al revés. La velocidad es un efecto secundario del trabajo que está haciendo su equipo. Es no un factor causal - es decir. es algo que mides y no es algo que puedas modificar directamente.
Esta explicación de la velocidad tiene un dato relevante para su pregunta.
Y según esa definición, un sprint más largo significa más tiempo para el desarrollo por sprint y, por lo tanto, un mayor número de velocidad.
La velocidad relativa entre un sprint de 2 o 3 semanas es una pregunta ligeramente diferente. Los gastos generales de las ceremonias del proyecto pueden afectar cuánto se puede hacer porque hay menos tiempo total disponible. Considere este cálculo como una forma de identificar las horas de desarrollo disponibles en un sprint.
DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevsCeremonyOverheadEn general es fijo. Disminuye tuDaysInSprinty puedes ver cómo tendrás menos tiempo disponible para el desarrollo durante ese sprint. Usando un ejemplo simple de 1 dev, aquí están los números para algunas longitudes de sprint.La respuesta "obvia" es que los sprints más largos son mejores. El problema con la respuesta obvia es que ignora el impacto beneficioso de los circuitos de retroalimentación. Reflexione sobre ese cálculo con una perspectiva general de lo que se supone que Agile debe aportar al proceso de desarrollo.
Sospecho que su problema principal es que sus historias de usuario no están tan definidas como podrían estar. Esa falta de comprensión de lo que se requiere es el impedimento real para realizar el trabajo.
fuente
Esta es una gran bandera roja. Si lo ve como una ceremonia en lugar de un vehículo esencial que sirve al proceso de trabajo y su mejora, probablemente trabajar en eso tiene más ganancias que jugar con la longitud del sprint.
El proceso está en tus manos (es decir, el equipo). Se supone que debes perseguir las ideas más atractivas, si necesitas experimentar y ajustar. Estábamos haciendo 2 semanas y luego cambiamos a 3 semanas y funcionó mejor. Pero a veces solo establece la longitud en función de la estimación del alcance. Sí, soy consciente de la idea de "igual longitud", pero no es un dogma, y puede que realmente no encaje con algún proyecto de la vida real. Y tener un objetivo de sprint claro y evidente puede servir mejor.
La longitud adecuada no es algo que pueda deducirse del exterior. Estás allí para conocer los factores relevantes. En la planificación, puede comenzar con "ok, qué podemos hacer en las próximas X semanas". O, en cambio, "cuál sería el próximo incremento sensible". En cualquier caso, planificar esto último es bueno, entonces mira qué tiempo tomaría. Y parte eso en uno o más sprints.
fuente
Depende de usted. Pruebe ambos, vea lo que funciona. Usa eso.
El mejor 'sprint' ágil que alguna vez usé fue de 6 semanas. Hicimos mucho, pero solo necesitábamos entregar al cliente en ese horario. No utilizamos tareas, preferimos trabajar al estilo de trabajo de la historia del usuario.
fuente
Depende de lo que describas como un "nuevo equipo".
De hecho, la velocidad de un equipo depende de muchos parámetros entre muchos (es decir, juniors, seniors, recién llegados, tensiones entre los miembros del equipo, etc.).
Por lo tanto, la longitud del sprint "ideal" también está vinculada a estos parámetros.
De todos modos, no hay una solución inmediata para eso, la única forma es probarlo con el equipo en sí mismo y también tener en cuenta el mejor ajuste promedio para todos los miembros del equipo.
fuente
Cuestiono su sugerencia de un "ciclo de retroalimentación más corto". Su equipo debería estar trabajando con sus clientes a diario; los comentarios no deberían esperar a la revisión y retrospectiva de Sprint. Pruebe, codifique, diseñe y obtenga comentarios de inmediato .
Personalmente, me gusta el sprint de tres semanas porque la semana intermedia le permite al equipo algo de tiempo de "flujo". Es decir, siempre hay tanto tiempo acelerando la primera semana (aprendiendo qué diablos significan estas nuevas historias) y algo finalizando la última (preparándose para la revisión). Una semana media para simplemente producir software de trabajo es algo realmente bueno.
Llevando esta lógica más lejos, los sprints de cuatro semanas tendrían aún más sentido. Sin embargo, el sentido de urgencia puede perderse si comienza a extender sus sprints. Además, realmente hay una porción relativamente pequeña de información que una persona o equipo puede captar y retener en su pensamiento consciente al mismo tiempo: cuanto más largo sea el sprint, más cosas en las que estás tratando de enfocarte, lo que puede hacer que las cosas sean más difíciles en lugar de más fácil. Además, es más difícil juzgar qué factores externos se introducirán si extiendes las cosas demasiado lejos.
fuente
Como preguntaste sobre un nuevo equipo, quería agregar algunas ideas. He estado trabajando con Scrum y otros métodos ágiles durante más de 15 años y ahora siempre recomiendo que los nuevos equipos comiencen con Sprints de 1 semana. Hay tres razones críticas para esto:
Escribí un artículo llamado 21 Consejos para elegir una longitud de Sprint que podría ser de interés.
fuente
Las ceremonias tienen un propósito: cuando reconocemos el propósito, nos damos cuenta de que no son gastos generales, sino un valor agregado.
Planificación : no solo se trata de comprometerse a trabajar, sino también de comprender cómo trabajar con sus compañeros de equipo. Cuando las personas se quejan de la falta de colaboración en su equipo Scrum, me gusta ver su planificación de Sprint como parte del problema
Revisión : recopile comentarios del cliente sobre lo que estamos creando y sigue siendo relevante, etc. También actúa como un control de calidad.
Retrospectiva : mejore la forma en que trabajamos juntos como equipo.
Cuando nos esforzamos por honrar el propósito más profundo, el problema general generalmente desaparece. Como se señaló en los comentarios originales a la pregunta, las ceremonias generalmente se escalan linealmente.
Si necesita más información sobre el tema, tengo un artículo: Cómo elegir una longitud de Sprint
fuente