Olá Rodrigo,
tem algumas estratégias que você pode tomar dependendo do contexto. Vou dar umas sugestões que você pode experimentar. Ou então você se basear nestas ideias e testar uma nova.
Como você comentou, na hora de quebrar as tarefas você pode ter uma delas para fazer uma análise da arquitetura como um todo. E errar a estimativa de esforço e dificuldade acaba sendo relativamente comum em historias complexas como essa dado que seu grau de incerteza é bem grande. Nestas situações em que erramos na expectativa, você pode conversar com o PO e ver dele talvez repriorizar as histórias e tarefas para deixar esta parte mais complexa para ser feita depois e não travar o que ainda tinha sido planejado para a sprint. Ou se esta user story é algo prioritário pro PO , acaba já deixando ele a par da situação e avisado que talvez nem todas as tarefas prometidas na sprint serão entregues por conta deste imprevisto. Aí na retrospectiva o time discute como evitar que este problema ocorra novamente e tomar mais cuidado também na hora de estimar no próximo planning.
Outra coisa que você pode tentar é no planning, quando o cliente apresentar uma user story complexa, tentar quebrá-la em mais user story menores e priorizá-las. Que aí você consegue negociar de entregar uma parte nesta sprint e outras ficam para as próximas.
Mais um ponto nesta situação é que se uma tarefa dessas acaba impactando tantos sistemas isso já é um indicativo de que talvez a qualidade do código não esteja tão boa, porque existe um alto grau de acoplamento dado que tantos lugares serão impactados. Então talvez valha a pena negociar com o PO de fazer refatorações no código nas próximas sprints para subir a qualidade do código, dado que isso pode fazer com que as próximas histórias e tarefas tenham uma menor complexidade.
São algumas ideias sobre o que eu tentaria fazer. A chave aqui é você ir testando ideias de como resolver o problema é ver qual acaba servindo para o seu contexto.
