Muchas historias de usuarios comparten las mismas tareas técnicas: ¿qué hacer?

Una pequeña introducción a mi caso:

Como parte de un producto más grande, se le pide a mi equipo que realice un pequeño IDE para un DSL. El usuario de este producto podrá realizar llamadas de función en el código y también se nos pedirá que proporcionemos algunas bibliotecas de funciones útiles. El equipo, junto con el PO, colocó en la pared una cierta cantidad de historias de usuarios sobre las diversas bibliotecas para el usuario IDE. Al estimar la primera de esas historias, el equipo decidió que el mecanismo de llamada de función habría sido una tarea atractiva pero no completamente obvia, por lo que la estimación de esa historia de usuario se elevó de un simple 3 a un 5 más peligroso.

Llegando al problema:

Luego, el equipo pasó a las historias de usuario con respecto a las otras bibliotecas, en realidad 10 historias, y agregó esos 2 puntos de " mecanismo de llamada de función " a cada una de esas historias de usuario. ¡Esto elevó inmediatamente el total de puntos para el producto de 20 puntos! Todos en el equipo saben que el PO puede recoger cada historia de usuario para la próxima iteración en cualquier momento, por lo que no debemos aislar esa parte en una historia de usuario, ¡pero esos 20 puntos se sienten tan poco realistas!

He propuesto una solución, pero no estoy absolutamente satisfecho:

Creamos una "Historia de diseño" y pusimos esos 2 puntos molestos sobre ella. Sin embargo, cuando nos dimos cuenta y lo demostramos a nuestros clientes, ¡no pudimos mostrarles algo realmente valioso sobre esa historia!

Aquí el problema es si debemos ignorar el principio de tener historias de usuarios aisladas (sin ninguna dependencia entre ellas).

¿Qué harías, o incluso mejor, qué has hecho en situaciones como esta?

(una pequeña nota al pie: siguiendo una sugerencia, he movido esta pregunta de stackoverflow)

Si necesita estimar varias historias de usuario que tienen algunos elementos en común, pero aún no sabe en qué orden deben implementarse estas historias, dividiría las tareas que componen cada historia en tres grupos:

1. Tareas comunes, necesarias una vez : tareas que se producen para varias historias, pero que solo deben realizarse una sola vez para la primera historia. El mecanismo de llamada de función mencionado probablemente caería en esta categoría.
2. Tareas comunes y repetidas : tareas que se producen en varias historias y deben ejecutarse nuevamente para cada historia.
3. Tareas específicas : tareas específicas para una historia en particular.

Luego estima cada tarea, donde las tareas comunes deben estimarse solo una vez.

En la presentación al cliente / PO, daría dos estimaciones para cada historia: una con todas las tareas "comunes, necesarias una vez" incluidas y una con ellas excluidas.
Simplemente mantenga una contabilidad detallada de las tareas, su clasificación y estimación a la mano si el cliente desea información más detallada sobre la diferencia entre las estimaciones. Las tareas en sí no son negociables, pero conocerlas podría ayudar al cliente / PO, especialmente si el conjunto de tareas comunes no es el mismo para cada historia.

Por qué el software es difícil.

Creamos una "Historia de diseño" y pusimos esos 2 puntos molestos sobre ella. Sin embargo, cuando nos dimos cuenta y lo demostramos a nuestros clientes, ¡no pudimos mostrarles algo realmente valioso sobre esa historia!

Correcto. La historia de usuario simplista SCRUM es simplista. A veces, el software real es lo suficientemente complejo como para que el enfoque simplista no funcione. Esto no debería ser una sorpresa.

Aquí el problema es si debemos ignorar el principio de tener historias de usuarios aisladas (sin ninguna dependencia entre ellas).

Cual es tu alternativa ¿Sobrevalorar cada historia de usuario porque cada una tiene un costo único oculto? Eso es igualmente tonto.

Si. Tienes que alejarte de lo simplista.

¿Qué harías, o incluso mejor, qué has hecho en situaciones como esta?

Aléjate de lo simplista. Hay inversiones únicas que hacen que un grupo de historias sea menos costoso. En realidad, debe hablar con la gente sobre la arquitectura en lugar de pretender que su única interacción es una lista de historias que se construirán.

Ágil significa que realmente tiene que hablar con la OP y los clientes.

Ágil significa que un proceso simplista no puede funcionar, y no funcionará.

Sabes que solo tienes que hacer el trabajo extra una vez, por lo que poner el mismo trabajo extra en 5 historias no tiene sentido. Si no desea una historia de diseño que el usuario no pueda ver, entonces lo mejor que puede hacer es seguir adelante, ahora mismo, y elegir una de las cosas que dependen de ese trabajo de diseño y decir que tiene que ser lo primero y agrega esos puntos a ese. Tome notas sobre las otras historias que tienen que venir más tarde, y si, por alguna razón, cambia de opinión, siempre puede mover los puntos.