Как правильно разделить разработку веб-проекта на юзер-стори?
Как всегда и везде, люди не до конца изучили agile/scrum и что то постят..
Ни где четко не прописано что заказчик должен быть вовлечен в процесс. 
В первую очередь, SCRUM это управленческий фреймворк который позволяет упорядочить процессы, наладить коммуникации и поставлять инкременты итеративно.
В каком виде будет выглядеть ваш инкремент это уже решать вам лично. В виде юзер стори, в виде чеклиста/идеи/тасков/эпиков и т.п.
Если мы говорим о настоящем Agile Scrum, то собираем команду, изолируем её от всего кроме нашего проекта и дальше по методологии:
(тут есть только 2 простейших процесса где нужен заказчик на 1-2 часа в 2 недели. типичная ошибка, звать его везде как этому учат на дурацких тренингах за 1000$)
1. Собираем с заказчика хотелки и пихаем в беклог
2. Собираемся и грумим беклог дробя эпики на мелкие стори или еще мельче эпики
3. Делаем спринт пленинг и дробим беклог на задачи, поочередно оценивая всё
4. Согласовываем инкремент и какой Definition of Done
5. Работаем итерацию попутно проводя дейли статус митинги для синхронизации статусов и раннего выявления проблем
6. Демонстрируем в конце что получилось, собираем от заказчика фидбек и форматируем беклог, возвращая в него то что не готово и все что не влезло в спринт
7. Делаем ретроспективу и убеждаемся что копаем в нужном направлении и не делаем ничего лишнего либо добавляем в процессы работы то что стоило бы делать
8. Возвращаемся к пункту 1
Добавлю, что в беклоге может быть всё начиная от эпиков, юзер стори и заканчивая отдельными задачами, багами и т.п. 
Когда вы начинаете оценивать стоимость и сроки проекта под Agile/Scrum вы наступаете на теже грабли. Если заказчик не знает на что он идет то это не Agile.
Наши клиенты уже с шишками и готовы платить деньги не представляя стоимости проекта в целом и тем более его сроков. С большего это стартапы. На опыте запуски и провалы хороших проектов. Один из них уже 4й год на рынке и поднял 20 лямов инвестиций в США и сейчас является одним из успешных интернет магазинов в США.
Изначально на кармане у заказчика было денег понты и работало 2 человека на проект - бекенд и айос и копали-копали пока не выросли до постоянной команды в 5 человек (бекенд, фронтенд, айос, андроид, qa) которые непрерывно работают на проекте и копают спринтами один за другим. И ни кто никого не гонит. Заказчик купается в бабле
"Проект должен пройти в любом случае через" этим вы уже отстраняете себя от гибкой методологии.
А далее user story это просто маленькие задачки, притом целостные.
И эти задачки должны иметь бизнес цену.
К примеру "добавить функцию в API" для бизнеса в разы ценнее, чем "Добавить анимацию на кнопку".