Longitud de Sprint - 2 semanas vs 30 días

Question

Quiero implementar Scrum, pero no puedo decidir sobre la longitud de Sprint. Ken Schwaber parece relatar que hace 30 días que es el defacto ... pero no me puedo imaginar esperando 30 días sin la posibilidad de cambiar de dirección o volver a priorizar.

Nuestros proyectos usualmente duran de 1 a 3 meses usando el método de la cascada y mudarse a Scrum probablemente significaría menos oportunidad de afinar.

Estaba pensando en sprints de 1 semana, pero esto parece Scrum Micro Management.

Tener carreras de 2 semanas probablemente sería ideal, pero quiero saber si otras personas pudieron implementar esto con éxito. ¿Cuáles son los inconvenientes? ¿Es más trabajo/menos trabajo/lo mismo sobre el trabajo para administrar un equipo con sprints más cortos?

BTW ... Los sprints de 3 semanas me parecen raros, ¿quién hace un sprint de 3 semanas? ¿Por qué no hacerlo solo 4 semanas? ;)

Answer 1

He trabajado en equipos que realizan carreras de 1, 2 y 4 semanas. Realmente depende de tu organización. Prefiero sprints de 1 o 2 semanas. El equipo actual que estoy ejecutando está en los sprints de 4 semanas porque estamos coordinando esfuerzos de 12 productos diferentes. Estoy buscando moverlos a iteraciones de 2 semanas pronto.

La clave para definir la longitud es llegar a "hecho, hecho". Para algunos equipos, esto significa en producción. Para otros, puede significar que el negocio los verifique para satisfacer sus necesidades utilizando una versión interna. Comenzaría por definir hecho, hecho, y luego mirar cómo estructurar tus sprints alrededor de eso. Idealmente, todas las historias se están haciendo al final del sprint, y no solo estás haciendo Scrummerfall.

Answer 2

2 semanas (10 días laborables estándar, si eres un equipo M-F o 12 si eres un equipo M-S) es de medio mes (un mes generalmente tiene aproximadamente 20 días hábiles, más o menos). Además, la semana es más vaga que el día pero menos vaga que el mes, por lo que mejora la unidad de medida en semanas para proyectos de desarrollo más ágiles (más dar/recibir).

Sin embargo, la última vez que hice algo así como scrum, fue en un proyecto de la escuela y no era realmente scrum. Entonces fueron 7 días de semanas en un trimestre de 10 semanas. Me gustó mucho el bloque de 2 semanas para esa situación. Sentí que podía hacer mucho, pero podíamos ajustar los plazos y los planes con frecuencia.

Answer 3

Me gustan dos semanas. Obliga a una caja de tiempo razonable sobre los problemas pero le permite ver los resultados a un ritmo reforzante. 30 días es para siempre Una semana podría ser fácilmente el ritmo adecuado para un producto en rápido movimiento como un sitio web.

Answer 4

Ahora mismo estamos haciendo sprints de 30 días y consiguiendo pilas. Una razón por la cual los sprints de 30 días nos funcionan bien es que nuestra planificación y estimación generalmente demora 2 días (reuniendo y decidiendo qué tareas de alto nivel tomar de la acumulación, tomando las tareas de alto nivel y descomponiéndolas, poniendo estimaciones sobre la descomposición tareas, y luego asignarlas). También reservamos 2 o 3 días para corregir errores y realizar pruebas.

Ya estamos en 5 días allí, por lo que hacer sprints de 2 semanas solo nos dejaría con 5 días de R & D. 30 días ha sido un gran equilibrio para nosotros hasta ahora.

Answer 5

Las longitudes de Sprint pueden variar de un proyecto a otro, pero deben permanecer constantes en el mismo proyecto. Lo mejor que puedes hacer es tratar de encontrar la longitud de sprint más cómoda para tu equipo, he estado usando Scrum durante dos años y ahora nos hemos conformado con veinte sprints de días de trabajo.

Mi experiencia me dice que en los proyectos que requieren entregas rápidas y una programación relativamente simple (operaciones CRUD, cuadrículas y formularios simples, etc.) es más prudente ir a sprints más cortos, como dos semanas. Para cosas con mayor complejidad (como frameworks) probablemente sea mejor ir a sprints más largos, como sprints de cuatro semanas. Mi proyecto actual se inclina hacia la última opción.

Pero lo importante es elegir la longitud cómoda tanto para el equipo como para el propietario del producto.

Answer 6

El propietario del producto siempre debe tener la oportunidad de cambiar las prioridades y las indicaciones. Uno de los propósitos de SCRUM es aceptar los cambios y dejar que el propietario del producto sea el responsable de la prioridad al analizar las necesidades del negocio y el equipo de desarrollo responsable de la entrega a tiempo.

Así que incluso si tiene un sprint de 3 semanas, tampoco significa que el dueño del producto tiene que esperar 3 semanas si descubre algo que (posiblemente) va a romper el sprint.

En algunos casos excepcionales, debe detener un sprint en el medio y crear uno nuevo debido a nueva información o nuevas prioridades.

Answer 7

Estaba pensando en 1 semana de sprints, pero esto parece ser Scrum Micro Management.

Sí, pero esto hará que haga más Scrum: hará una planificación de sprints, una demostración de iteración y una retrospectiva cada semana. La desventaja es la sobrecarga, sin embargo, pasas menos tiempo planificando, haciendo demostraciones y "revisando" una iteración de una semana que una iteración de un mes.

Cuanto más corta es la iteración, más rápido el equipo aprende el proceso.

Ahora, dependiendo del tipo de proyecto, puede ser difícil lograr algo valioso en un retraso de una semana.

Antes me olvidaba, no hago tres semanas de iteración: o)

En caso de ir con cuatro semanas iteraciones, también tiene la posibilidad de sustituir las tareas que no han sido iniciadas con tareas estimados para el la misma cantidad de tiempo

Answer 8

Trabajé en sprints de 1,2,3 y 4 semanas. El sprint de 1 semana es demasiado corto para completar los compromisos del equipo, 2 es ideal, cuando traté de implementar un sprint de 3 o 4 semanas no podemos utilizar el equipo de QA de manera efectiva. (El control de calidad tendrá más tiempo de inactividad en la primera semana)