Muitas histórias de usuários compartilham as mesmas tarefas técnicas: o que fazer?

Uma pequena introdução ao meu caso:

Como parte de um produto maior, minha equipe é solicitada a realizar um pequeno IDE para uma DSL. O usuário deste produto poderá fazer chamadas de função no código e também é solicitado que você forneça algumas bibliotecas de funções úteis. A equipe, juntamente com o PO, publicou um certo número de histórias de usuários sobre as várias bibliotecas para o usuário do IDE. Ao estimar a primeira dessas histórias, a equipe decidiu que o mecanismo de chamada de função teria sido uma tarefa envolvente, mas não completamente óbvia; portanto, a estimativa dessa história de usuário aumentou de um simples 3 para um mais perigoso 5.

Chegando ao problema:

A equipe então mudou-se para as histórias de usuários referentes às outras bibliotecas, na verdade 10 histórias, e adicionou esses 2 pontos de " mecanismo de chamada de função " a cada uma dessas histórias de usuários. Isso elevou imediatamente o total de pontos para o produto de 20 pontos! Todos na equipe sabem que cada história de usuário pode ser escolhida pelo OP para a próxima iteração a qualquer momento, portanto, não devemos isolar essa parte em uma história de usuário, mas esses 20 pontos parecem muito irrealistas!

Propus uma solução, mas não estou absolutamente satisfeito:

Criamos uma "história de design" e colocamos 2 pontos irritantes sobre ela. No entanto, quando percebemos e demonstramos a nossos clientes, não conseguimos mostrar algo realmente valioso para eles sobre essa história!

Aqui, o problema é se devemos ignorar o princípio de ter histórias de usuários isoladas (sem nenhuma dependência entre elas).

O que você faria, ou melhor ainda, o que você fez, em situações como essa?

(uma pequena nota de rodapé: seguindo uma sugestão, mudei esta pergunta do stackoverflow)

Se você precisar estimar várias histórias de usuários que têm alguns elementos em comum, mas ainda não sabe em que ordem essas histórias serão implementadas, dividiria as tarefas que compõem cada história em três grupos:

1. Tarefas comuns, necessárias uma vez : tarefas que ocorrem para várias histórias, mas que só precisam ser executadas apenas uma vez na primeira história. O mecanismo de chamada de função mencionado provavelmente se enquadra nessa categoria.
2. Tarefas comuns e repetidas : tarefas que ocorrem em várias histórias e precisam ser executadas novamente para cada história.
3. Tarefas específicas : tarefas específicas para uma história específica.

Então você estima cada tarefa, onde as tarefas comuns devem ser estimadas apenas uma vez.

Na apresentação ao cliente / OP, eu daria duas estimativas para cada história: uma com todas as tarefas "comuns, necessárias uma vez" incluídas e uma com elas excluídas.
Apenas mantenha uma contabilidade detalhada das tarefas, sua classificação e estimativa em mãos, se o cliente desejar informações mais detalhadas sobre a diferença entre as estimativas. As tarefas em si não são negociáveis, mas o conhecimento delas pode ajudar o cliente / OP, principalmente se o conjunto de tarefas comuns não for o mesmo para cada história.

Por que o software é difícil?

Criamos uma "história de design" e colocamos 2 pontos irritantes sobre ela. No entanto, quando percebemos e demonstramos a nossos clientes, não conseguimos mostrar algo realmente valioso para eles sobre essa história!

Corrigir. A história simplista do usuário SCRUM é simplista. Às vezes, o software real é complexo o suficiente para que a abordagem simplista não funcione. Isso não deve ser uma surpresa qualquer.

Aqui, o problema é se devemos ignorar o princípio de ter histórias de usuários isoladas (sem nenhuma dependência entre elas).

Qual é a sua alternativa? Superestimar o preço de cada história de usuário porque cada uma delas tem um custo único oculto? Isso é igualmente bobo.

Sim. Você tem que se afastar de simplista.

O que você faria, ou melhor ainda, o que você fez, em situações como essa?

Afaste-se do simplista. Existem investimentos únicos que tornam um grupo de histórias mais barato. Você precisa conversar com a gente sobre a arquitetura em vez de fingir que sua única interação é uma lista de histórias a serem construídas.

Ágil significa que você precisa realmente conversar com o OP e os clientes.

Ágil significa que um processo simplista não pode - e não vai - funcionar.

Você sabe que só precisa fazer o trabalho extra uma vez; portanto, colocar o mesmo trabalho extra em cinco histórias não faz sentido. Se você não quer uma história de design que o usuário não pode ver, a melhor coisa a fazer é seguir em frente, agora, e escolher uma das coisas dependentes desse trabalho de design e dizer que deve ser a primeira e adicione esses pontos a esse. Faça anotações nas outras histórias que elas devem vir mais tarde e, se, por algum motivo, você mudar de idéia, sempre poderá mudar os pontos.