Наверно у вас был не скрам, а «скрам, но» (scrum, but), судя по проблеме. В скраме программистам дают бизнес задачу, они сами погружаются на этапе оценки в проблему и обсуждают все (в том числе с аналитиками) от уровня бизнес постановки до реализации чуть ли не в классах. [и только после этого оценивают]. А проблема, похожая на вашу, на моем опыте часто возникала, когда на словах декларируется скрам, а по сути программистам без объяснений спускается 500-страничное ТЗ и пилится по задачам. Ну да, нормальный программист он ленивый и будет читать не весь документ а только нужную часть.
Лечится возвращением к основам — адекватный backlog груминг, планирование и обзоры спринта всей командой с заказчиком и обратной связью.
При таком подходе возникает и другая проблема: команда не фиксирует принятые решения, описание предметной области. То есть “в скраме” отсутствует документооборот, все на словах.
В сложных, длительных проектах критически важно фиксировать знание в документах. Иначе команда будет замедляться, ввиду растущей сложности решения и непонимания предметки.
Нужны выделенная роль для ведения документооборота? Специальный аналитик, который фиксирует все решения команды?