User Story
User Story — краткое описание функциональности с точки зрения пользователя.
Формат
Как <роль/персона>
Я хочу <действие/функциональность>
Чтобы <бизнес-ценность/цель>
Примеры
Хороший пример
Как покупатель интернет-магазина
Я хочу фильтровать товары по цене
Чтобы быстро находить товары в моем бюджете
Плохой пример
Система должна иметь фильтр по цене
❌ Нет роли, нет ценности, техническая формулировка
Компоненты User Story
1. Заголовок
Краткое название (3-5 слов)
Примеры:
- Фильтр товаров по цене
- Регистрация через email
- Экспорт отчета в Excel
2. Описание (As-Want-So)
Основной текст в формате выше.
3. Критерии приемки (Acceptance Criteria)
Конкретные условия, при которых Story считается выполненной.
Формат Given-When-Then:
Дано: <начальное состояние>
Когда: <действие пользователя>
Тогда: <ожидаемый результат>
Пример:
Дано: Пользователь на странице каталога
Когда: Выбирает диапазон цен от 1000 до 5000 руб
Тогда: Отображаются только товары в этом диапазоне
И: Количество найденных товаров показано сверху
И: Фильтр можно сбросить кнопкой "Очистить"
4. Приоритет
- Must have — критично для релиза
- Should have — важно, но не критично
- Could have — желательно
- Won't have — не в этом релизе
5. Оценка
Story Points (1, 2, 3, 5, 8, 13, 21)
6. Зависимости
Связи с другими Stories или техническими задачами.
INVEST критерии
Хорошая User Story должна быть:
Independent (Независимая)
Можно реализовать в любом порядке, минимум зависимостей.
❌ Плохо:
- Story 1: Создать таблицу пользователей в БД
- Story 2: Реализовать регистрацию
✅ Хорошо:
- Story: Регистрация пользователя (включает создание таблицы)
Negotiable (Обсуждаемая)
Детали можно уточнять, это не жесткий контракт.
Valuable (Ценная)
Приносит ценность пользователю или бизнесу.
❌ Плохо: Рефакторинг кода авторизации ✅ Хорошо: Ускорение входа в систему (через рефакторинг)
Estimable (Оцениваемая)
Команда может оценить сложность.
Если не можем оценить:
- Недостаточно информации → нужен spike
- Слишком большая → разбить на меньшие
- Слишком много неопределенности → исследование
Small (Небольшая)
Можно реализовать за 1 спринт (обычно 1-5 дней).
Признаки что Story слишком большая:
- Оценка > 13 Story Points
- Описание занимает больше страницы
- Много критериев приемки (>10)
- Затрагивает несколько подсистем
Решение: Разбить на меньшие Stories (вертикальный слайсинг)
Testable (Тестируемая)
Можно проверить что Story выполнена.
❌ Плохо: Система должна быть быстрой ✅ Хорошо: Страница загружается за < 2 секунд
Шаблоны User Stories
Регистрация
Как новый пользователь
Я хочу зарегистрироваться через email
Чтобы получить доступ к функциям сервиса
Критерии приемки:
- Форма содержит поля: email, пароль, подтверждение пароля
- Email валидируется (формат)
- Пароль минимум 8 символов
- После регистрации отправляется письмо подтверждения
- Пользователь перенаправляется на страницу "Подтвердите email"
Поиск
Как пользователь
Я хочу искать товары по названию
Чтобы быстро находить нужный товар
Критерии приемки:
- Поле поиска в шапке сайта
- Поиск начинается после ввода 3+ символов
- Результаты показываются в реальном времени
- Показывается до 10 результатов
- Клик по результату открывает страницу товара
- Если ничего не найдено — показывается сообщение
Экспорт данных
Как менеджер
Я хочу экспортировать отчет о продажах в Excel
Чтобы анализировать данные в Excel
Критерии приемки:
- Кнопка "Экспорт в Excel" на странице отчета
- Файл скачивается автоматически
- Формат: .xlsx
- Содержит все колонки из таблицы
- Название файла: sales_report_YYYY-MM-DD.xlsx
- Экспортируются только видимые строки (с учетом фильтров)
Разбиение больших Stories
Вертикальный слайсинг
Разбиваем по функциональности, каждая часть приносит ценность.
Большая Story: "Личный кабинет пользователя"
Разбиение:
- Просмотр профиля
- Редактирование профиля
- Смена пароля
- Загрузка аватара
- История заказов
Горизонтальный слайсинг (избегать!)
Разбиваем по техническим слоям.
❌ Плохо:
- Создать таблицу в БД
- Создать API endpoint
- Создать UI форму
Проблема: Ни одна из этих Stories не приносит ценность отдельно.
Связь с Use Case
Use Case — детальное описание сценария взаимодействия.
User Story — краткое описание потребности.
Соотношение:
- 1 Use Case = 5-10 User Stories
- Use Case описывает "как", Story — "что" и "зачем"
Пример:
Use Case: "Оформление заказа"
- Основной сценарий (10 шагов)
- Альтернативные сценарии
- Исключения
User Stories из этого Use Case:
- Добавление товара в корзину
- Изменение количества в корзине
- Удаление товара из корзины
- Ввод адреса доставки
- Выбор способа оплаты
- Подтверждение заказа
Частые ошибки
1. Технические Stories
❌ "Создать REST API для пользователей" ✅ "Регистрация нового пользователя"
2. Слишком большие
❌ "Реализовать личный кабинет" (20 SP) ✅ Разбить на 5-7 меньших Stories
3. Нет критериев приемки
❌ Только описание As-Want-So ✅ Добавить конкретные Given-When-Then
4. Нет бизнес-ценности
❌ "Рефакторинг кода" ✅ "Ускорение загрузки страницы"
5. Слишком детальные
❌ "Кнопка должна быть синей, 120x40px, шрифт Arial 14pt..." ✅ "Кнопка подтверждения заказа" (детали в дизайне)
Инструменты
- Jira — управление Stories, спринты
- Trello — простые доски
- Azure DevOps — для Microsoft стека
- Linear — современный, быстрый
- Notion — гибкий, но не специализированный
Шаблон в Jira
Summary: Фильтр товаров по цене
Description:
Как покупатель интернет-магазина
Я хочу фильтровать товары по цене
Чтобы быстро находить товары в моем бюджете
Acceptance Criteria:
- [ ] Слайдер с двумя ручками (мин/макс цена)
- [ ] Диапазон от 0 до максимальной цены в каталоге
- [ ] Фильтр применяется автоматически при изменении
- [ ] Показывается количество найденных товаров
- [ ] Кнопка "Сбросить фильтр"
- [ ] Работает вместе с другими фильтрами
Story Points: 5
Priority: High
Sprint: Sprint 15
Полезные ресурсы
- Книга "User Story Mapping" — Jeff Patton
- Книга "User Stories Applied" — Mike Cohn
- Mountain Goat Software