¿Deberíamos crear subtareas para cada historia de forma predeterminada que representen todos los diferentes tipos de trabajo que requerirá la historia?

La propuesta de agregar subtareas a cada historia de usuario por adelantado para cada tipo de trabajo involucrado en completar la historia de usuario asume una forma diferente de trabajar con subtareas de la que está haciendo actualmente.

Presuntamente, la persona que hizo la propuesta tenía en mente que la historia de usuario seguiría siendo el PBI que se estima y planifica. Las subtareas serían, por un lado, un recordatorio para el equipo mientras estiman la historia qué trabajo implica completar la historia del usuario y, por otro lado, proporcionarían una división fácil del trabajo cuando varias personas comiencen a trabajar en la historia.

Esto significa que esas subtareas no se estimarían individualmente (y definitivamente no en puntos de la historia según una secuencia de Fibonacci) y tampoco se planificarían individualmente. Todo eso sucede en el nivel de la historia del usuario.

Si decide aceptar esta propuesta, tendrá que pensar en cómo lidiar con las historias de usuarios que son demasiado grandes para una sola iteración y que actualmente divide en subtareas, porque usar ambas prácticas al mismo tiempo solo causaría confusión. Una alternativa aquí podría ser dividirse en dos historias de usuario y promover la historia demasiado grande a un Epic o poner ambas historias nuevas bajo el mismo Epic (existente).

Este es un enfoque bastante común adoptado por muchos equipos. A menudo, a los equipos les resulta útil tener esas subtareas para organizar su trabajo. Al mismo tiempo, no es estrictamente necesario. Muchos equipos lo hacen bien sin ellos. La única trampa es que debe asegurarse de que el enfoque no se mueva tanto a las subtareas que la atención deje los elementos pendientes. Esos elementos de la cartera de pedidos siguen siendo los que entregan valor.

Otro punto que compartiría es cómo se crean normalmente esas subtareas. Si observa la estructura de Sprint Planning en la guía Scrum, hay tres partes: el por qué, el qué y el cómo. La primera parte establece la dirección del sprint, lo que generalmente resulta en un Sprint Goal preliminar. La segunda parte identifica en qué elementos del backlog trabajar que conducirán al resultado propuesto en la primera parte. La tercera parte es un espacio para que el equipo cree un primer paso en el plan sobre cómo cumplir con esos elementos. Aquí es normalmente donde se crearían esas subtareas. En ese momento, las subtareas correctas para crear son aquellas que ayudan al equipo a organizar su trabajo para entregar los elementos del backlog seleccionados y cumplir con el objetivo del sprint. Esto conduce a valiosas subtareas que se alinearán con el trabajo que se debe realizar.

En mi opinión, la sugerencia de su colega es excelente . "Las 'historias' se refieren a lo que el usuario finalmente verá, ¡no a la prestidigitación que se requerirá para que finalmente lo vea!

Si sucede que, en su "tienda", las "historias" que llegan se pueden subdividir de manera útil en clases, especialmente clases que sugieren algún tipo de implementación común o enfoque reutilizable, entonces creo que debería aprovechar de inmediato sobre la idea y ponerla en marcha.

Las "historias", después de todo, son deliberadamente una abstracción. Pero, en su situación de botas sobre el terreno, esto es algo concreto.