Descomposición artificial en Scrum

¿Parece que Scrum no aborda este problema de ninguna manera?

No, no lo hace.

Scrum es una guía. Aunque prescribe cosas, no prescribe muchas cosas. Esta es una de las cosas que quedan a discreción del implementador. Por ejemplo, solía proporcionar una muestra de 3 preguntas para hacer durante el día, pero finalmente se descartaron (probablemente porque muchos tomaron esas preguntas según lo prescrito y se centraron solo en ellas en lugar de pensar por sí mismos).

En ese párrafo la guía dice que se deben descomponer las cosas para que el equipo las entienda y pueda hacerlas en un sprint. Cuanto más pequeño, mejor, porque ese refinamiento aumenta la comprensión, minimiza las incógnitas y los riesgos, y evita hacer suposiciones sobre las cosas . No se menciona cuán pequeños o cuán grandes, solo que pueden caber en un sprint (aunque un consejo común que escuchará, y la regla general, es aproximadamente 1-2 días por PBI).

Por supuesto, la vida no sigue las reglas de Scrum todo el tiempo. Cuando gira algo por todos sus lados y aún no puede encajarlo en un sprint y entregarlo en un incremento, debe usar el sentido común para saber cómo manejarlo. A veces, se necesita más que un Sprint para hacer algo, s # sucede, por lo que lo aborda de una manera diferente (lo que decida el equipo con el PO). Pero la idea es que esto sea la excepción, no la regla .

Sé que hay una respuesta aceptada, pero me parece que tiene un poco de trampa, por lo que quiero proporcionar esta respuesta para otra vista.

He estado practicando Scrum durante aproximadamente 15 años y todavía tengo que encontrar una tarea que no pueda dividirse de manera útil en menos de un sprint. Esto ha sido en industrias que van desde la construcción hasta el marketing y la investigación en computadoras cuánticas. Sin embargo, me he encontrado con tareas que no pude desglosar en ese momento. En estos casos, creo que es importante intentarlo como en la vieja universidad, pero no obsesionarse con eso. Reconoce que no sabes cómo, luego ponte a trabajar. Sin embargo, el aprendizaje es una parte fundamental de Scrum. Cuando encuentre estos y termine esas tareas, mire hacia atrás y encuentre formas en retrospectiva en las que podría haber hecho piezas. Esto es mucho más fácil y así es como llegué al punto en que podría decirte cómo dividiría cualquier tarea que haya hecho en menos de un sprint y hacer que entregue algo útil.

Editar: Esto es para completar la idea de "útil". Quiero decir que hace progresar significativamente el producto sin trabajo adicional. Esto puede ser la eliminación de riesgos, la respuesta a preguntas comerciales, comerciales o técnicas, la funcionalidad del usuario y la atención de otras necesidades del usuario, como el rendimiento o la seguridad. Esto no incluiría la planificación, la lectura de tecnología u otras tareas parciales.

En primer lugar, los elementos de la cartera de pedidos generalmente no deberían ser "tareas" en absoluto. Siempre que sea posible, los elementos de la cartera de pedidos deben ser entregables, funciones u otros resultados. ¿Tiene un ejemplo de un artículo pendiente que no se puede dividir? La mayoría de los grandes entregables se pueden dividir.

Considere un sprint típico que consta de 10 días hábiles (2 semanas es probablemente la duración más común del sprint) y un equipo de 8 personas (los equipos Scrum suelen tener entre 3 y aproximadamente 10 personas). Eso significa que un elemento pendiente es algo que debería poder hacerse con menos de 80 días de esfuerzo. El esfuerzo de 80 días es un costo bastante grande y mucho trabajo para poner en riesgo de una sola vez. Si los elementos de su cartera de pedidos son realmente tan grandes, es casi seguro que vale la pena el esfuerzo de desglosarlos porque hacerlo reduce el riesgo de entrega y, en última instancia, mejora la productividad.

Si realiza una búsqueda de "división de historias", encontrará muchos ejemplos de formas interesantes de dividir los elementos pendientes.

Para complicar aún más la situación de la vida real, puede haber dependencias complejas entre las tareas identificadas, lo que refleja la arquitectura del sistema subyacente. Scrum es, y solo puede ser, una guía. Tómelo por las muchas ideas muy buenas que contiene, pero no lo adore.