У нас в стартапе выработался анти-паттерн, который пока работает и мы его не трогаем.

Когда мы работаем над фичей, я создаю таску в GitHub Issues. В ней содержится только контекст проблемы, краткое описание решения и acceptance criteria. По мере того как мы обсуждаем фичу, таска дополняется деталями. В таске практически никогда нет UX, мы очень редко дизайним что-то отдельно в Фигме.

Когда разработчики начинают работать над фичей, какие-то решения они принимают сами, какие-то мы принимаем вместе. Таким образом, детальные требования и UX формируются в процессе разработки.

Когда фичу уже можно показать команде, создаётся Pull Request, в котором детально описываются все принятые решения, скриншоты и т.п. Там же идёт дискуссия в комментах, в результате которой фича дорабатывается на той же ветке и в конце концов идет в прод.

Наша продуктовая документация — пулл-ревкесты, прилинкованные к таске. Это не очень удобно пост-фактум, когда хочешь посмотреть как было принято то или иное решение. Это возникает нечасто, зато коллаборация в PR делает обсуждения ближе к коду, то есть прямо в том контексте, где происходит работа.

Этот процесс не смасштабируется, когда у нас будет больше людей или нетехнический продакт. Но пока этот органический процесс работает, мы его не трогаем, чтобы не было как в анекдоте:

Сколько программистов нужно, чтобы подоить корову?
Пять, один держит корову за вымя, остальные 4 поднимают за ногу.

То, что мы делаем, не соответствует правилам скрама, но соответствует духу Agile Manifesto. Мы сами формируем процесс, который позволяет нам быстро принимать решения.

Аспект "соответствия духу" вместо "следования процессу" — то, что часто не понимают апологеты скрама. Если интересно копнуть глубже, можете послушать/посмотреть наше интервью с одним из авторов Agile Manifesto Дэйвом Томасом.