User Story — краткое описание функциональности с точки зрения пользователя. Это основной формат постановки задач в Agile-командах. Хорошие User Stories ускоряют разработку, плохие — создают хаос.
Классический формат
As a [type of user], I want [action/goal], so that [benefit/value].
На русском: Как [роль пользователя], я хочу [действие/цель], чтобы [польза/ценность].
Примеры хороших User Stories
1. Как покупатель, я хочу фильтровать товары по цене, чтобы быстро найти подходящие по бюджету варианты.
2. Как водитель такси, я хочу видеть предполагаемый заработок до принятия заказа, чтобы принимать выгодные решения.
3. Как пользователь мобильного банка, я хочу оплачивать покупки по QR-коду, чтобы не носить с собой карту.
4. Как HR-менеджер, я хочу автоматически получать отчёт по отпускам команды, чтобы планировать загрузку.
Примеры плохих User Stories
❌ Как пользователь, я хочу красивый дизайн — нет конкретики и измеримости. ❌ Добавить кнопку «Купить» — это задача, а не User Story. ❌ Как админ, я хочу REST API для пользователей — техническая задача без пользовательской ценности.
INVEST-критерии качественной User Story
- Independent — независима от других stories, можно делать в любом порядке - Negotiable — обсуждаема, не контракт, а приглашение к разговору - Valuable — приносит ценность пользователю или бизнесу - Estimable — можно оценить трудозатраты - Small — достаточно маленькая для выполнения за спринт - Testable — можно проверить выполнение
Acceptance Criteria (критерии приёмки)
User Story без AC — это wishful thinking. AC определяют, когда story считается выполненной.
Формат Given-When-Then:
Given [начальное условие] When [действие пользователя] Then [ожидаемый результат]
Пример AC для фильтра по цене: - Given я на странице каталога товаров - When я устанавливаю фильтр цены от 5000 до 15000 ₸ - Then отображаются только товары в этом диапазоне - And количество товаров обновляется без перезагрузки страницы - And URL обновляется с параметрами фильтра (для шаринга)
Декомпозиция больших Stories (Epics)
Если story не помещается в спринт — это Epic. Декомпозируйте:
1. По workflow: регистрация → верификация email → заполнение профиля 2. По типу пользователя: новый пользователь vs возвращающийся 3. По платформе: web → mobile → API 4. По данным: создание → чтение → редактирование → удаление (CRUD) 5. По happy/unhappy path: успешный сценарий → обработка ошибок
User Story Mapping
Техника визуализации всех stories продукта на одной карте: - Горизонталь: шаги пользовательского пути (journey) - Вертикаль: детализация и приоритет (MVP → Nice to have)
Инструменты: Miro, StoriesOnBoard, физическая доска со стикерами.
Типичные ошибки
1. Story = задача — User Story описывает ЧТО и ЗАЧЕМ, а не КАК. 2. Слишком большие stories — если нельзя сделать за спринт, декомпозируйте. 3. Нет Acceptance Criteria — без AC разработчик додумывает детали сам. 4. Технические stories без пользовательской ценности — рефакторинг нужно привязывать к пользовательским целям. 5. Одинаковая детализация для всех stories — stories ближайшего спринта детализируем, остальные можно оставить крупнее.
Шаблон для Jira/Notion
``` User Story: Как [роль], я хочу [действие], чтобы [ценность]. Acceptance Criteria: - [ ] Given... When... Then... - [ ] Given... When... Then... Out of Scope: - Что НЕ входит в эту story Design: [ссылка на Figma] Technical Notes: [для разработчика] ```
Ресурсы для углубления: - User Story курс (Udemy, Coursera) - «User Stories Applied» (Mike Cohn) — классическая книга - Примеры User Stories — поищите "user story examples" на GitHub и Medium
Визуализация ключевых концепций
Предпросмотр кода
flowchart TD
subgraph Format["Формат User Story"]
AS["As a [роль]"]
WANT["I want [действие]"]
SO["so that [ценность]"]
end
AS --> WANT --> SO
subgraph AC["Acceptance Criteria"]
GIVEN["Given [условие]"]
WHEN["When [действие]"]
...