В случае малого ресурса себя, как БА, что бывает почти всегда, я бросаю все силы на выяснение общего объёма работ (выяснение скоупа).

Пока этого нет, сложно оценивать раскопки вглубину, так как непонятно что собственно копаем.

Скоуп в любом случае выявляется в самом начале. Вопрос как раз в том, что для дальнейшей работы команды необходимо конкретизировать каждый пункт. При недостатке ресурса получается либо груда основных процессов, в которых содержится куча неуточнённых данных, либо всего один из трёх более-менее проработанный технический проект для внедрения. В первом случае прилетает от внедрения, во втором - от менеджеров.

Интерес какраз в том, чтобы найти "золотую середину", когда внедрение уже само "допрёт" как сделать, а оставшееся время пустить на другие проекты.

Если скоуп грамотно определён вначале, то в нём есть приоритеты реализации тех или других фич. Из них следуют приоритеты задач.

Хм. интересно

Т.е. задачи с низким приоритетом лучше вообще опускать и фокусироваться на приоритетных вещах?

Это как раз момент, в котором золотую середину нужно искать совместно с теми, кто данными будет пользоваться. А не вымучивать самостоятельно.

Да, ведь приоритет родился из реальных предпосылок бизнеса.
Если есть сомнение, что они не очень логичны, то видимый риск надо доносить до руководства.

Честно сказать, похоже, что БА - это похожа на тренировку "третьего глаза" или инфрокрасного зрения. Долго долго присматриваться к чему-то маленькому, чтобы потом научитсья видеть чуть больше, а потом ещё больше. Вначале видишь только по 5 секунд, потом чуть больше и т.д.

Вроде бы и ящик, брык на 5 секунд это уже другой обхект, брык - снова ящик =)

Это зависит от того с кем и на каких проектах работаешь. Если вокруг все несутся и "надовсё вчера", то такие озарения будут происходить внезапно. Вообще методы анализа позволяют при уважительно выделенном времени посмотреть на объект с разных точек зрения и на разном уровне абстракции:
сейчас это объект автоматизации,
сейчас это автоматизирующая система,
сейчас это то, за что заказчик платит деньги,
сейчас это то, что мы разрабатываем.

Если проект большой, то попадание в скоуп из разряда ахалай махалай

Это если он определён и забыт.
У меня есть мечты о том, что когда-нибудь скоуп будет определяться для того, чтобы отслеживать его изменения и оценивать их в деньгах, времени, трудозатратах и в чём ещё нужно. Он будет меняться, но меняться предсказуемо!
*Мечтательно закатила глаза

Вот да. Сколько раз было когда бизнес понимал что "Вот без этой фичи нам вообще все остальное не нужно". И изменение скоупа приводило или к закрытую проекта или увеличению всего

Вот! Это правильный сценарий работы со скоупом!

Ну или классический вариант. Больше функционала за теже деньги

А если посмотреть бабок то там есть такая штука как заинтересованные стороны, конкретно по типам:
business analyst,
• customer,
• domain subject matter expert,
• end user,
• implementation subject matter
expert,
• operational support,
• project manager,
• regulator,
• sponsor,
• supplier, and
• tester.

так вот все эти стороны по идее вовлекаются в процесс обсуждения требований. Причем end user это лишь один из. и по идее их всех надо так или инчае привлекать)

оптимальный вариант лежит в плоскости рисков. Ты смотришь и думаешь где оно веротянее всего завалится. и топаешь к люядем которые будут потом проект валить