Scrum: corto vs largo sprint

8

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?

— Avi
fuente

1

Si bien la planificación y la retrospectiva son más frecuentes, ¿no tienes también 2/3 de las que hablar? Y así, ¿no puedes acortar la reunión?

— pdr

3

Mi experiencia con scrum muestra que la retrospectiva tomará el mayor tiempo posible. La planificación puede ser un poco más corta, pero no estoy lo suficientemente seguro. Además, hay una demostración de los clientes / po y la reunión de revisión de sprint.

— Avi

2

Eso deja dos posibilidades. 1. Su retrospectiva fue, quizás aún es, demasiado corta. No vea eso como un tiempo improductivo, porque aumenta su productividad el resto del tiempo. 2. Su retrospectiva carece de estructura y no está logrando mucho. En cuyo caso la solución es obvia.

— pdr

1

Aproximadamente 1: no tiendo a aceptar que fue breve. A las personas de mi equipo les encanta hablar :) Tratamos de mantenernos enfocados, pero a menudo sucede que la discusión deriva a lugares donde no se logrará nada productivo. Enmarcar el tiempo en la retrospectiva ayuda a cortar esa discusión y volver al camino de una discusión productiva con conclusiones claras y acciones para el futuro. En cuanto a 2: estoy de acuerdo y últimamente estoy investigando formas de mejorar nuestras retrospectivas. Mabye, abriré una pregunta diferente para retrospectiva.

— Avi

1

@pdr: Hay un costo fijo para cada reunión (por ejemplo, antes y después de una interrupción no va a trabajar en nada serio). Por lo tanto, menos reuniones pueden ser más eficientes que muchas reuniones cortas.

— Giorgio

8

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.

La forma más simple de definir la velocidad es: el número o historias de usuarios que un equipo / proyecto puede hacer en un sprint

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 * NumberOfDevs

CeremonyOverheadEn general es fijo. Disminuye tu DaysInSprinty 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.

1 semana:
((8 * 5) - 4) * .8 = 28.8 horas o 5.76 horas por día.
2 semanas:
((8 * 10) - 4) * .8 = 60.8 horas o 6.08 horas por día.
3 semanas:
((8 * 15) - 4) * .8 = 92.8 horas o 6.18 horas por día.

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.

1

Ese no es el problema en absoluto. Realmente trato de pensar, objetivamente, cómo tomar tal decisión.

— Avi

2

@Avi: aparte de mi especulación, ahora puedes ver los efectos cuantitativos de diferentes longitudes de sprint. Simplemente ingrese los números apropiados para su equipo con respecto a los gastos generales y su factor de utilización. A partir de ahí, tiene un acto de equilibrio entre la duración del sprint y el impacto sobre el ciclo de retroalimentación. Para el caso, Agile alienta a hacer las cosas de manera diferente para experimentar de manera constructiva e identificar medios de mejora. Cambie las longitudes de su sprint por un tiempo y vea cuáles son los resultados.

3

Dijiste "CeremonyOverhead generalmente está arreglado". ¿No deberían tus rituales de sprint escalar con el tamaño de tus sprints? Este artículo afirma que "las reuniones de sprint escalan linealmente con la duración de un Sprint. Entonces, un Sprint de una semana tendrá 2 horas de Planificación de Sprint, un Sprint de dos semanas tendrá 4 horas y así sucesivamente". lo cual puede ser un poco optimista, pero debería ser casi lineal.

— sgryzko

7

Por otro lado, hay muchas desventajas, como ceremonias (planificación, retrospectiva), etc.

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.

— Balog Pal
fuente

1

Estoy de acuerdo con tu diagnóstico. Las reuniones serán breves, simples y efectivas por un equipo experimentado. Las reuniones largas que el equipo intenta evitar son un signo seguro de una implementación rota de ágil.

— Sklivvz

2

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.

— gbjbaanb
fuente

Sé que depende de mí y cada equipo tiene sus preferencias. Sin embargo, quería reunir algunas cosas que hacer y qué no hacer para tomar una buena decisión al principio. Por cierto. En este proyecto de sprint de 6 semanas, ¿tuvo más de un sprint?

— Avi

6 semanas parece mucho para un sprint, quizás demasiado. Creo que, en la mayoría de las situaciones, si pasas más de 4 semanas con un sprint, probablemente lo estés haciendo mal ...

— Radu Murzea

Creo que gbjbaanb solo tenía 6 semanas para el proyecto. O en otras palabras, el proyecto fue solo 1 sprint. Por supuesto, incluso un proyecto de 6 semanas se puede dividir en sprints de 1-2-3 semanas.

— Avi

Teníamos unos 6-8 meses de trabajo por hacer. Dio la casualidad de que 6 semanas fueron buenas para nosotros y para el cliente que revisó nuestras entregas, y ese es el punto: ignore a cualquiera que diga qué debería ser un sprint . Es lo que te hace más productivo. Recuerde, ágil dice entregar software de trabajo regularmente, no dice 2 semanas. He trabajado en sprints de 2 semanas donde tuvimos que investigar mucho para hacer la entrega, en cada extremo las demostraciones fueron vergonzosas en su brevedad, y los comentarios de ellos fueron intrascendentes. Así que tuvimos muchos gastos generales por poco resultado. YMMV

— gbjbaanb

1

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.

— Vincent
fuente

1

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.

— Matthew Flynn
fuente

1

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:

Los Sprints más cortos ayudan a los equipos a alcanzar un estado de alto rendimiento más rápido. Los sprints largos generalmente significan que lleva de 18 meses a dos años llegar a ese estado. Los Sprints cortos de una semana ayudan a un equipo a alcanzar ese estado de alto rendimiento en solo dos o tres meses. Por supuesto, otras cosas también deben estar en su lugar para alcanzar un alto rendimiento (ver "La sabiduría de los equipos" de Katzenbach y Smith).
Como otros han mencionado, un Sprint más corto aumenta el ciclo de retroalimentación. Un Sprint de una semana parece ser óptimo para la mayoría de los equipos que realizan desarrollo de software o desarrollo de productos. La retroalimentación debe ser principalmente durante la Revisión de Sprint, que debe tomar el lugar de su proceso tradicional de UAT.
Finalmente, los Sprints más cortos presionan a su equipo para que lidie con los obstáculos de la organización para la entrega frecuente. Al principio, esa presión es muy incómoda, pero es esencial para mejorar sus procesos de desarrollo en general, incluida la planificación, el cumplimiento, los lanzamientos, etc.

Escribí un artículo llamado 21 Consejos para elegir una longitud de Sprint que podría ser de interés.

— Mishkin Berteig - Entrenador ágil
fuente

0

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

— Mark Levison
fuente