¿Por qué usar iteraciones en Scrum?

TL; DR

En realidad tienes dos preguntas. Uno es sobre el tiempo de caja, y el otro es sobre la estimación.

El time-boxing y la estimación son la esencia misma de Scrum. Si no está adaptando esas dos prácticas para su equipo, lo que sea que esté haciendo no es realmente Scrum.

Las herramientas y prácticas no son balas de plata

[El desarrollo incremental] simplemente no parece traer suficiente bondad a nuestro equipo.

El time-boxing es una herramienta. No es un fin en sí mismo, es un medio para un fin. Los objetivos del time-boxing incluyen:

1. Componer historias de usuario más granulares.
2. Aplicación de límites implícitos de trabajo en curso.
3. Mejorar la precisión de la estimación.
4. Desarrollar una cadencia predecible dentro del proyecto.

Time-Boxes: Esencial para Scrum

[¿Qué tan valioso es exactamente mantener una iteración con límite de tiempo?

El time-boxing es esencial para el marco. Garantiza que el trabajo tenga el tamaño adecuado, que las características se programen en función de la capacidad del equipo y que el proyecto tenga un ciclo de retroalimentación estricto para sus entregables.

La duración de los time-boxes se puede ajustar, pero no puedes prescindir de ellos. De hecho, la duración del sprint es uno de los diales de control más efectivos para un proyecto.

• Carreras más cortas...

  • acelerar el circuito de retroalimentación.
  • aumentar la sobrecarga del proceso.
  • reducir los límites WIP implícitos.
  • reducir el tamaño máximo de la unidad de trabajo.
  • reducir los tiempos de ciclo para unidades de trabajo del tamaño adecuado.

• Carreras más largas...

  • reducir la sobrecarga del proceso.
  • aumentar el tamaño máximo de la unidad de trabajo.
  • generalmente aumentan el esfuerzo requerido para la integración de funciones.
  • aumentar el tiempo disponible para implementar controles de proceso a costa de tiempos de ciclo más largos.

Tienes que encontrar la longitud de sprint óptima para tu equipo. Es muy probable que los sprints de una semana sean demasiado cortos para los requisitos de su organización.

Time-Boxing y Estimación trabajan de la mano

[E]nunca ha habido un sprint en el que completemos con éxito TODAS las tareas planificadas. Siempre completamos la mayoría de ellos, pero siempre quedarán algunos para el próximo sprint. Tal vez tenga algo que ver con que solo 2 personas están contribuyendo a la estimación.

Voy a hacer algunas suposiciones aquí. En primer lugar, no cuenta con la suficiente aceptación o participación del equipo para confiar en sus estimaciones, por lo que descuenta el valor de la estimación. En segundo lugar, debido a que su trabajo se estima incorrectamente, está incorporando más trabajo en cada sprint de lo que la capacidad de su equipo puede soportar.

Todos los equipos pierden ocasionalmente los objetivos de compromiso, pero el hecho de no cumplirlos de forma rutinaria es una señal de un problema de proceso fundamental. En su caso, es probable que esto se deba a una duración de iteración incorrecta, estimaciones de historias inexactas o historias que se introducen en cada sprint desde fuera del equipo sin tener en cuenta los límites WIP o la capacidad del equipo.

Soluciones posibles

Puede mejorar las estimaciones de su equipo con el tiempo mediante el uso de algunas prácticas ampliamente aceptadas. Algunas de estas prácticas incluyen:

1. Una sesión formal de Sprint Planning donde participa todo el equipo.
2. Planning Poker para alentar las estimaciones no ancladas y promover la discusión sobre la variación en las estimaciones.
3. Retrospectivas de Sprint donde se pueden revisar las estimaciones para identificar las lecciones aprendidas sobre el proceso de estimación del equipo.
4. Promover la propiedad colectiva o el enjambre en lugar de asignar historias a miembros individuales del equipo.

Puede mejorar la velocidad de su equipo y la tasa de finalización de la historia siguiendo las pautas del marco. Las mejores prácticas incluyen:

1. Ajustar la duración del sprint al tamaño óptimo para su historia de usuario típica.
2. Revisar sus expectativas de velocidad a la baja cuando no se cumplen los objetivos de compromiso.
3. Limitar las historias aceptadas en cada sprint en el extremo inferior de su rango de velocidad previsto.
4. Trabajar con el propietario del producto para descomponer las historias de usuario que no encajan en un solo sprint.

Ver también

• Respuesta relacionada sobre cómo la duración del sprint puede afectar la sobrecarga del proceso.
• Respuesta relacionada que analiza el enjambre y los límites WIP.

Creo que debería preguntarse "¿Por qué el equipo no está lo suficientemente comprometido para proporcionar estimaciones?"

Esto puede ayudarlo a llegar a la raíz de sus problemas, que sospecho que es más probable que sea un problema de liderazgo en algún nivel que uno de proceso. Deberá intensificar y tratar de mitigar estos efectos trabajando para involucrar a todo el equipo. Siéntese con los miembros del equipo que no brindan estimaciones y, de la manera más positiva y no conflictiva posible, averigüe por qué. Tome esta información y trabaje para volver a involucrar al equipo para que no solo contribuyan a generar estimaciones, sino que también se apropien.

En cuanto al problema más sintomático de los timeboxes, si no establece una fecha límite para una tarea, nunca se realizará cuando la necesite. Uno puede discutir todo el día sobre cuánto debe durar un período de tiempo para un proyecto en particular, una iteración, un producto o un elemento de acción, pero no creo que la necesidad básica de establecer límites sobre cuánto tiempo debe tomar algo sea discutible.

Me parece que está mezclando dos cosas: la priorización de las tareas que se realizarán en el próximo Sprint y la estimación de tareas. Las partes interesadas del proyecto deben priorizar las tareas, y el equipo estima cuántas tareas caben en el próximo sprint (generalmente 1-2 semanas). Los sprints con límite de tiempo son buenos para establecer las expectativas adecuadas con el Cliente y para las iteraciones de implementación (solo el código listo y probado pasa a la implementación por etapas cada semana).

Si está comenzando los sprints los lunes, el martes de la semana anterior organice una sesión con la parte interesada del proyecto (Cliente) para crear una lista priorizada de elementos que se realizarán la próxima semana. Puede que no vaya rápido, pero digamos que el miércoles el cliente te enviará la lista. El jueves invite a 3 o 4 desarrolladores calificados a una sesión de Planning Poker (no vale la pena llevar a todo el equipo a una sesión de estimación). Calcule cada elemento de la lista en Story Points. Dividir características grandes en otras más pequeñas. Vea cuántos Story Points se realizaron anteriormente (Sprints anteriores) y reduzca su lista de tareas a aproximadamente el mismo tamaño de Story Points. Si hay dudas, aclararlas con el Cliente y los Desarrolladores el viernes. Envíe por correo electrónico la lista corta al Cliente para establecer las expectativas correctas. Comience a trabajar en Sprint el lunes; es probable que esta breve lista esté terminada en Sprint.

Probablemente no todos los sprints coincidan exactamente con sus estimaciones, eso es simplemente imposible de lograr siempre, sin embargo, después de 10 sprints, es probable que sea más eficiente en la estimación.

Las iteraciones con timeboxed son buenas para establecer la velocidad. Tomará varias iteraciones, pero en algún momento podrá decir que el equipo puede terminar, digamos 15 a 20 puntos en una iteración de una semana.

La desventaja de no establecer una velocidad aproximada es que no se puede hacer ninguna planificación. Si su cartera de pedidos es, digamos, de 300 puntos, y es necesario incorporar una nueva iniciativa, no podrá decidir si la prioridad se puede reorganizar o si necesita contratar a más personas o subcontratar el trabajo.

Si permitimos que una o dos personas dedicadas mantengan una lista estrictamente priorizada y muestren los entregables según sea necesario, ¿cuál es la desventaja?

La desventaja: cuando no hay plazos específicos, las tareas suelen tardar más de lo que deberían.

Más específicamente: "El trabajo se expande hasta llenar el tiempo disponible para su realización". -- Ley de Parkinson

Si ese tiempo es infinito (sin fecha límite), bueno... puedes ver a dónde lleva eso.

... ¿cuán valioso es exactamente mantener una iteración en un cuadro de tiempo?

En mi experiencia, es bastante valioso.

No veo al equipo completando todas las funciones, incluso si todos contribuyen a las estimaciones.

Este es un problema totalmente separado, es posible que desee editarlo y enviarlo como una pregunta separada.

Pero ciertamente no recomendaría alejarse de las iteraciones con límite de tiempo para abordar un problema con la estimación y la entrega.

Hay algunas sugerencias valiosas en otras respuestas, pero pensé en compartir lo que mi equipo ha estado haciendo.

Desde hace bastante tiempo, no hemos hecho planificación de sprints ni estimación de puntos de historia.

Lo importante es que mire cuidadosamente por qué hace esas cosas y las reemplace con otra que le dé el mismo resultado, de una manera que funcione mejor para su equipo.

Para mi equipo, decidimos que la Planificación de Sprint se hiciera por tres razones:

1. Para darle al PO una idea de lo que completaríamos en ese sprint, para que pueda comunicar el progreso a otras partes.
2. Para darle al equipo la oportunidad de confirmar la intención de una historia con el PO y discutir cualquier criterio de aceptación poco claro.
3. Para verificar que, dado lo que hemos aprendido desde que estimamos originalmente una historia, los puntos que se le dieron todavía sonaban bien y volver a estimar si es necesario.

En segundo lugar, decidimos que la estimación (que hicimos en una sesión separada) es valiosa para nosotros, nuevamente por tres razones:

1. Para comunicar una historia al equipo y permitir que el equipo cuestione la PO.
2. Forzar una conversación sobre la complejidad y los riesgos que implica una historia.
3. Para garantizar que una historia no sea demasiado grande para trabajar en un sprint.

Por lo tanto, analizamos las formas en que podíamos generar los mismos resultados de diferentes maneras, dejamos de planificar e introdujimos:

Sesiones de trabajo pendiente : este es un espacio de 30 minutos cada día (aunque solo se usa "según sea necesario") donde el propietario del producto presenta las próximas historias al equipo. Luego los discutimos a un alto nivel, identificamos dónde podemos necesitar clavos o una sesión de diseño técnico para elaborar y decidir si es de un tamaño que estamos dispuestos a aceptar o si necesita romperse (la regla general es si pensamos podemos hacerlo en una semana). Esto reemplaza los puntos 4, 5 y 6.

Story Huddles : esto tiene lugar cuando comienza una historia, generalmente entre el dolor del desarrollador, BA, QA y PO. Es una oportunidad para asegurarnos de que hemos capturado los criterios de aceptación, tener una idea de las pruebas que necesitamos escribir y podemos dividir una historia si empezamos a pensar que es demasiado grande para hacerla como una sola. Esto reemplaza los puntos 2 y 3.

Tiempo de ciclo como métrica : en lugar de medir la velocidad, solo medimos cuánto tiempo lleva completar la historia promedio. Supervisar esto a lo largo del tiempo nos ayuda a identificar cuándo aumenta el tamaño/la complejidad de nuestra historia y también brinda información sobre la programación de la orden de compra (si tengo 5 cosas que quiero hacer y el tiempo del ciclo es de 4 días, debería tenerlas todas en 20 días). Esto reemplaza el punto 1.

Esto funciona para nosotros, pero le aconsejo que siga el mismo proceso que hicimos nosotros y examine qué valor obtiene de su proceso actual antes de realizar cualquier cambio.