user-stories

User Stories — ловушки

Формулировка

Story без value (So that)

Плохо: "Как пользователь, я хочу страницу настроек" — нет зачем Правильно: "Как пользователь, я хочу настроить уведомления, чтобы получать только релевантные" Почему: без value нельзя приоритизировать, команда не понимает зачем строить

Техзадача как story

Плохо: "Как разработчик, я хочу внедрить Repository pattern" Правильно: это Task внутри story, не отдельная story. Story = пользовательская ценность Почему: tech task без user value не проходит INVEST (Valuable), прячет реальную потребность

Технологии в description

Плохо: "Использовать Redis для кэширования, RabbitMQ для очередей" Правильно: технологии в Technical Notes, description описывает поведение Почему: story = обещание разговора, технические детали решаются при refinement с командой

INVEST

Not Independent

Плохо: "Зависит от story X" — нельзя взять в спринт без другой story Правильно: включи зависимость в scope или объедини stories Почему: зависимая story блокируется если предшественник не готов, спринт проваливается

Not Negotiable

Плохо: детальная спецификация на 3 страницы с точными UI layout Правильно: story = обещание разговора, детали уточняются при refinement Почему: жёсткая спецификация убивает креативность команды и не учитывает технические реалии

Not Estimable

Плохо: "Слишком много неизвестных, не можем оценить" Правильно: Spike story для исследования (timeboxed), потом оценка основной story Почему: без оценки невозможно планировать спринт, spike снимает неопределённость

Not Small (13+ SP)

Плохо: story на 13+ story points, работа на 2+ спринта Правильно: split по workflow (happy path, errors), rules (валидация, права), data (CRUD) Почему: большая story не помещается в спринт, прогресс непредсказуем

Acceptance Criteria

AC нетестируемые

Плохо: "Всё работает правильно" или "Работает корректно" Правильно: Given-When-Then с конкретными значениями: Given 3 неверных пароля When ввод 4-го Then блокировка 15 мин Почему: QA не может проверить "правильно", конкретные значения = автоматизируемый тест

Только happy path в AC

Плохо: AC покрывает только успешный сценарий Правильно: happy path + error + edge cases: неверный пароль, блокировка, истёкший токен, SQL injection Почему: 80% багов в error handling. AC без edge cases = баги обнаруживаются на production

Пустые данные не учтены

Плохо: AC не описывает поведение при пустом списке Правильно: "Given 0 элементов Then показать 'Нет данных'" — не null, не пустая страница Почему: пустое состояние = первый опыт пользователя, null ломает UI

Concurrent access не учтён

Плохо: AC для одного пользователя, нет сценария одновременного доступа Правильно: "Given два пользователя редактируют одновременно Then второй получает conflict" Почему: без concurrency AC — last write wins, данные первого пользователя потеряны

Спецсимволы и граничные значения

Плохо: AC только для "нормальных" данных Правильно: имя O'Brien (апостроф), текст 500 символов (лимит), timezone разных часовых поясов Почему: спецсимволы ломают SQL/HTML, длинный текст ломает layout, timezone = разные даты

Чек-лист

• Story даёт value пользователю (не техзадача)
• INVEST: все 6 критериев проверены
• AC: happy path + error + edge cases
• AC: конкретные значения (не "правильно работает")
• Нет технологий в description
• Size: 1-8 SP (13+ -> split)
• Пропущенные сценарии проверены (пустые данные, concurrent, спецсимволы)