Molte storie di utenti condividono gli stessi compiti tecnici: cosa fare?

Se hai bisogno di stimare diverse storie di utenti che hanno alcuni elementi in comune, ma non sai ancora in quale ordine queste storie devono essere implementate, allora dividerei i compiti che compongono ciascuna storia in tre gruppi :

1. Attività comuni, necessarie una volta : attività che si verificano per più storie, ma che devono essere eseguite solo una volta per la prima storia. Il citato meccanismo di chiamata di funzione probabilmente rientrerebbe in questa categoria.
2. Attività comuni e ripetute : attività che si verificano in più storie e devono essere nuovamente eseguite per ogni storia.
3. Attività specifiche : attività specifiche per una determinata storia.

Quindi stimerai ciascuna attività, dove le attività comuni dovrebbero essere stimate una sola volta.

Nella presentazione al cliente / PO, darei due stime per ogni storia: una con tutte le attività "comuni, necessarie una volta" incluse e una con quelle escluse.
Basta tenere una contabilità dettagliata delle attività, la loro classificazione e stima a portata di mano se il cliente desidera informazioni più dettagliate sulla differenza tra le stime. Gli stessi compiti non sono negoziabili, ma conoscerli potrebbe aiutare il cliente / PO, soprattutto se l'insieme di compiti comuni non è lo stesso per ogni storia.

Perché il software è difficile.

We created a "Design story" and put those annoying 2 points over it. However when we came to realize and demonstrate it to our customers, we were unable to show something really valuable for them about that story!

Una corretta. La semplicistica user story SCRUM è semplicistica. A volte, il software reale è abbastanza complesso che l'approccio semplicistico non funziona. Questo non dovrebbe venire come nessun tipo di sorpresa.

Here the problem is whether we should ignore the principle of having isolated user stories (without any dependency between them).

Qual è la tua alternativa? Over-price ogni utente story perché ognuno ha un costo una tantum nascosto? È ugualmente sciocco.

Sì. Devi allontanarti dal modo semplicistico.

What would you do, or even better what have you done, in situations like this?

Allontanati dal semplicistico. Ci sono investimenti una tantum che rendono un gruppo di storie meno costoso. Devi effettivamente parlare con la gente dell'architettura invece di fingere che la tua unica interazione sia una lista di storie da costruire.

Agile significa che devi effettivamente parlare con l'OP e i clienti.

Agile significa che un processo semplicistico non può e non funzionerà.

Sai che devi fare il lavoro extra una sola volta, quindi non avere senso inserire lo stesso lavoro extra in 5 storie. Se non vuoi una storia di design che l'utente non può vedere, allora la cosa migliore da fare è andare avanti, proprio ora, e scegliere una delle cose che dipendono da quel lavoro di progettazione e dire che deve essere prima e aggiungi quei punti a quello. Prendi appunti sulle altre storie che devono venire dopo, e se, per qualche ragione, cambi idea, puoi sempre spostare i punti.