Карточка называется «Переделать фильтры в каталоге». В описании — одна строка: «см. макет». Исполнитель — фронтендер, который макет видел мельком на созвоне неделю назад. Через четыре дня работа сдана, продакт открывает каталог и не находит фильтр по бренду. Его обсуждали голосом, на встрече, куда фронтендер не попал. Переделывать придётся заново, а срок уже сгорел.
Перепишем ту же карточку иначе: «Покупатель, который ищет товар конкретного бренда, может отфильтровать каталог по бренду и сохранить фильтр при переходе между страницами — сейчас он теряется, и человек уходит с сайта раньше оплаты». Текста больше, но разница не в объёме. В новой версии появился человек, которому нужен результат, и условие, по которому понятно, что работа закончена.
Это и есть разница между задачей-напоминанием и пользовательской историей. Причём дело не в индивидуальном везении с формулировками. Согласно исследованию продуктовых компетенций Акселератора ФРИИ (2025 год, более 1 000 оценок сотрудников из ИТ, телекома, промышленности и финтеха), 74% специалистов показали средний уровень продуктовой экспертизы, и только 12% дотянули до продвинутого. Это значит, что полагаться на интуицию «опытного продакта» при постановке задач может позволить себе меньшинство команд. Остальным нужен формат, который работает даже в среднюю смену.
Дальше — разбор семи реальных формулировок из разных сфер, честный ответ на вопрос, сколько деталей в истории достаточно, и где юзер-стори вообще не нужна. А ещё — почему AI-подсказки иногда ломают историю быстрее, чем её улучшают.
Почему «сделать форму регистрации» — это не задача, а напоминание
У формулировки «сделать форму регистрации» есть три дыры, которые не видны сразу, потому что текст выглядит вполне конкретным. Во-первых, в ней нет субъекта: непонятно, кому эта форма вообще нужна и зачем. Во-вторых, нет результата — что изменится после того, как форма появится. В-третьих, нет границы, то есть момента, после которого работу можно закрыть, а не продолжать переделывать.
Отсюда и разъезжаются ожидания. Исполнитель слышит «сделать форму» и делает минимально рабочий вариант с тремя полями. Заказчик имел в виду форму с подтверждением по телефону, потому что без него отдел продаж получает мусорные заявки. Оба правы по тексту задачи и оба неправы по факту.
Руководство Atlassian формулирует хорошую пользовательскую историю просто: это маленькая единица работы с явно обозначенной ролью, шагами и признаком завершения. Звучит как требование к карточке в трекере, и это правильный уровень, на котором стоит о ней думать.
При этом важна оговорка, которую часто упускают при внедрении формата. Практики в обсуждении «Как не захлебнуться в User Stories» на Habr прямо пишут: история является инструментом коммуникации, а не заменой техническому заданию. Она не отменяет макетов, спецификаций API и описания алгоритмов. Она объясняет, зачем эти вещи вообще нужны, и держит команду сфокусированной на одном и том же результате.
Формула «Как <роль>, я хочу <действие>, чтобы <ценность>» известна почти всем, кто хоть раз проходил курс по Agile. Карточки при этом всё равно получаются пустыми. Причина обычно в том, что формулу применяют не к той единице работы: пытаются впихнуть в неё целый модуль вместо одного понятного шага пользователя.
Разбор семи формулировок: что именно не так и как переписать
Как написали и как переписать
Одна и та же работа описывается по-разному в зависимости от того, кто будет её принимать. Ниже — семь карточек из разных сфер: как они обычно выглядят в бэклоге, что в них непонятно команде, и как это читается после переформулировки.
| Как написали | Что непонятно команде | Как переписать |
|---|---|---|
| Доработать личный кабинет | Неясен объём: то ли косметика, то ли новая логика | Клиент с несколькими договорами видит их списком в личном кабинете и переключается между ними, чтобы не звонить менеджеру ради номера договора |
| Исправить баг с выгрузкой | Нет условий воспроизведения и признака, что баг действительно исправлен | Выгрузка за 12 месяцев завершается без ошибки на отчётах от 50 000 строк — сейчас падает после 20-й минуты |
| Сделать рассылку по базе | Непонятно, кому и зачем; риск попасть в спам-листы | Подписчик, который не открывал письма 90 дней, получает реактивационное письмо, чтобы мы не гасили домен рассылками в мёртвую базу |
| Онбординг новичков | Не ясно, что именно считается готовым онбордингом | Новый сотрудник в первый день находит все доступы и контакты на одной странице, чтобы не отвлекать руководителя вопросами «а где взять пароль» |
| Оптимизировать склад | Формулировка звучит как цель отдела, а не как работа на спринт | Кладовщик видит в задаче точное место хранения позиции, чтобы не обходить стеллажи дважды в поисках товара |
| Улучшить UX оплаты | Это не одна история, а целая эпопея из нескольких экранов | Разбивается на три: «клиент видит итоговую сумму с комиссией до нажатия кнопки оплаты», «клиент может оплатить картой без выхода из приложения», «клиент получает чек на почту сразу после оплаты» |
| Как пользователь, я хочу удобный интерфейс, чтобы мне было удобно | Формально правильный шаблон, но роль абстрактна, а ценность — тавтология | Переформулировать через конкретное действие: кто, что именно пытается сделать и что ему сейчас мешает |
Последняя строка — частый результат внедрения формата «для галочки». Команда выучила структуру «как … я хочу … чтобы …» и начала заполнять её словами, которые ничего не меняют по сути. Формула без содержания не лучше короткого «сделать форму», она просто длиннее.
Интересно, что привычка писать атомарно закрепляется быстрее, чем привычка не писать лишнего. В академической работе Improving the Writing Quality of User Stories (Utrecht University, 2026) четырём командам дали лёгкие рекомендации по критериям качества историй. Доля нарушений по признакам atomic (одна цель на историю) и minimal (без лишних деталей) заметно снизилась, причём эффект по атомарности сохранялся и после окончания эксперимента, а вот с минимализмом команды снова начинали «разъезжаться» без постоянной поддержки правилом. Другими словами, делить историю на одну цель люди учатся легко. Не добавлять в неё лишнее — только если требование держится на уровне шаблона карточки, а не на памяти автора.
Сколько деталей достаточно и где они должны лежать
Три слоя карточки задачи
У истории, критериев приёмки и подзадач разные вопросы, на которые они отвечают. История говорит, зачем и для кого делается работа. Критерии приёмки — как команда поймёт, что она сделана. Подзадачи — кто и в каком порядке её выполняет. Когда все три слоя сваливают в одно текстовое поле, получается «простыня», которую никто не дочитывает до конца.
Разумный ориентир по количеству критериев дают практики в обсуждении на форуме Scrum.org: если критериев набирается больше 6–8, это чаще сигнал к декомпозиции истории, чем повод их сокращать. На примере истории про улучшение оплаты из таблицы выше легко увидеть, как это работает. Если собрать в одну карточку условия по сумме с комиссией, способу оплаты и отправке чека, критериев наберётся за десяток, и половина из них будет конфликтовать друг с другом по приоритету. Три отдельные истории с тремя-четырьмя критериями каждая читаются и принимаются быстрее, чем одна с одиннадцатью. Деление крупной работы по приоритету удобно проверять через матрицу ценность против усилий: часть отколовшихся кусков может вообще не попасть в текущий спринт, если усилий требует много, а ценности даёт мало.
Критерий приёмки хорошо проверять одним правилом: он должен читаться в логике «да/нет», без оценочных слов вроде «быстро», «удобно» или «красиво». «Форма отправляется без перезагрузки страницы» — проверяемо. «Форма работает плавно» — нет, и спор о приёмке вернётся снова.
Мы спросили у Марии Корчагиной, руководителя продуктовой команды в сервисе доставки, сколько текста в карточке реально читают исполнители. «Если описание длиннее экрана, человек читает первые два абзаца и идёт переспрашивать в чате — то есть ровно то, от чего история должна была избавить. Работает обратное: короткое описание, зачем это нужно, и чек-лист из конкретных пунктов снизу. Чек-лист читают до конца, потому что по нему можно отчитаться».
Зафиксировать этот порядок один раз проще, чем договариваться заново в каждом новом проекте. Для этого удобен шаблон карточки задачи, где заранее разложены поля под каждый из трёх слоёв.
Пользовательская история и вариант использования: когда шаблон не подходит
Не всякую работу стоит упаковывать в формулу «как пользователь, я хочу». История фиксирует намерение и ценность. Вариант использования (use case) фиксирует последовательность шагов, включая альтернативные и ошибочные ветки, и для интеграционных или регуляторных задач вторая форма точнее. Если нужно описать, как система ведёт себя при обрыве соединения на третьем шаге оплаты, короткое «чтобы» из истории тут не поможет, а подробная схема шагов — поможет.
Есть несколько типов работ, для которых история избыточна или прямо вредна. Технический долг и рефакторинг без видимого пользователю эффекта: тут нет роли и ценности, которую стоило бы придумывать искусственно. Инфраструктурные задачи — настройка сервера или миграция базы не становится понятнее от притянутой формулы про пользователя. Исследования и эксперименты, где результат заранее неизвестен и натягивать на него критерий «да/нет» бессмысленно. Наконец, рутинные операционные работы вроде продления сертификата или ротации ключей: роль в них одна — инженер, который и так знает, зачем это делает. Для всего перечисленного логичнее завести отдельный тип карточки со своими полями, а не насиловать шаблон истории там, где он не нужен.
Обзор User stories as boundary objects in agile requirements engineering (Journal of Systems and Software, 2026), синтезировавший 14 индустриальных исследований, описывает историю как «пограничный объект» — общий предмет разговора между продактом, дизайнером и разработчиком. Если такой разговор между ролями объективно не нужен, нужды в истории тоже нет. Это снимает чувство вины, которое иногда возникает у команд: не каждая карточка обязана начинаться со слова «как».
Подробное «почему» помогает команде и мешает согласованию
Здесь есть контринтуитивный момент, который редко проговаривают вслух. Чем честнее в истории прописана причина, та самая часть «чтобы», тем сильнее команда фокусируется на реальной пользе. Согласование при этом идёт дольше: причина выносит на поверхность разногласия, которые при формулировке «сделать фильтры» просто никто не обсуждал.
Тот же обзор в Journal of Systems and Software подтверждает оба эффекта разом: маленькие истории лучше помогают команде адаптироваться к изменениям, а явное указание «почему» усиливает фокус на пользовательской ценности и одновременно усложняет согласование между участниками. Отказываться от «чтобы» из-за этого не стоит. Лучше заранее закладывать время на обсуждение, чтобы спор на дейли по простой с виду карточке не стал неожиданностью.
Вторая контринтуитивная линия связана не с текстом, а с тем, откуда он берётся. По данным того же исследования ФРИИ, самая слабая продуктовая компетенция в российских корпорациях — карта пути клиента: средний уровень владения навыком не превышает 44% от нормы. Проблема большинства пустых историй в духе «я хочу удобный интерфейс, чтобы было удобно» вообще не в стилистике. Автору попросту нечего поставить в поле «чтобы», потому что пользовательский путь не исследован. Переписывание формулировок без этого остаётся косметикой.
Практический вывод: часть «чтобы» стоит заполнять источником, а не воображением — ссылкой на интервью, тикет поддержки или цифру из аналитики. Практика карт пользовательских историй прямо связывает их качество со свежими интервью и продуктовой аналитикой, а не с внутренними инициативами отдела. Если в компании пока нет цельной картины пути клиента, разумнее сначала собрать её, например через карту пользовательских историй, а уже потом дробить на отдельные карточки в трекере. Такой переход, кстати, часто совпадает с моментом, когда команда перестаёт мыслить проектом как набором задач и начинает мыслить продуктом и ценностью для клиента.
Кейс Lyft: что даёт связка историй с планированием
Эффект от хорошо написанных карточек редко случается от переписывания одной формулировки. Он появляется, когда истории связаны между собой через сквозной пользовательский сценарий, а не разбросаны по разным эпикам без общей логики.
Lyft работает в более чем 600 городах США и Канады. До перехода на цифровые карты пользовательских историй команда сталкивалась с разрозненными приоритетами и отсутствием общего способа связать сценарий пользователя с планированием задач. После внедрения карт историй в Jira компания сообщает о росте скорости команды (velocity) на 20% по всем метрикам — кейс Lyft.
Здесь важно, что именно поменялось: команда стала видеть бэклог целиком.
Цифры из подобных кейсов легко прочитать неправильно. AYANA Estate после централизации процессов в одном трекере отчитывается в кейсе Asana об экономии 594 рабочих дней и более чем 11 000 закрытых задач — только относится этот результат к внедрению инструмента, перестройке процессов и обучению команды разом, а не к тому, как написана отдельная история. Такие числа стоит читать как верхнюю границу возможного, а не как обещание конкретного результата для вашей компании.
Для команды на 50–200 человек воспроизводимым результатом от улучшения формулировок будет не рост velocity на 20%, а более скромные, но измеримые вещи: сокращение числа задач, возвращённых на доработку после приёмки, и уменьшение времени между «готово» и «принято». Это и стоит мерить в первую очередь, об этом ниже.
Как собрать историю в карточке Shtab
Три слоя описания (зачем, как проверить, кто делает) удобно разложить по разным полям карточки — тогда исполнителю не приходится вычитывать сплошной текст в поисках сути.
В левой части карточки задачи в Shtab находится описание, файлы, чек-листы и подзадачи, ниже — комментарии для обсуждения работы. Начинать стоит с описания: что нужно сделать и какова конечная цель, это и есть та самая часть «для кого и зачем». Файлы и макеты можно прикрепить прямо в описание или в отдельное поле, чтобы исполнителю не пришлось искать их в переписке или на созвоне, который он пропустил.
Небольшие проверяемые шаги логично оформлять чек-листом: туда ложатся критерии приёмки, и по каждому пункту сразу видно, пройдена проверка или нет. Отдельные части работы со своими исполнителями и сроками — это подзадачи. Например, в истории про оплату одна подзадача на бэкенд, вторая на интерфейс, третья на отправку чека. Справа в карточке статус, исполнители, сроки и приоритет: кто отвечает, когда нужен результат и на каком этапе находится работа.
Если стандартных полей не хватает, можно добавить пользовательские — скажем, поле «источник потребности» со ссылкой на интервью или обращение клиента, и поле «роль пользователя». Источником такого поля часто становится обращение из почты или чата: в Shtab есть готовый сценарий, как превращать письма клиентов в задачи и отвечать прямо из Telegram, не теряя контекст запроса.
Для работ, которые не нужно упаковывать в историю — техдолг, исследования, инфраструктура, — можно создать отдельный тип карточки со своими полями вместо встречи или сделки. Стандарт описания должен применяться автоматически, а не держаться на памяти автора, и для этого пригодится шаблон карточки и группировка задач по типу или источнику. А чтобы автор истории видел изменения по своей карточке без вопросов «как там дела», в неё можно добавить наблюдателей. Если бэклог уже накопился в таблице, его можно сразу импортировать из CSV или XLSX, не переписывая вручную.
AI-подсказки: на каком шаге они помогают, а где разводят воду
Модель хорошо работает как рецензент уже написанной истории и как инструмент декомпозиции. Плохо — как автор истории с нуля, потому что причину «чтобы» знает только тот, кто разговаривал с пользователем.
В 2025–2026 годах инструменты генерации критериев приёмки на базе больших языковых моделей оценивают уже не по гладкости текста, а по релевантности, корректности, понятности и покрытию требований. В исследовании по генерации критериев приёмки эксперты оценили 81 критерий по четырём измерениям и в среднем сочли результат приемлемым. Параллельно в материалах IEEE описан инструмент контекстной генерации критериев для историй. Вывод из обоих источников один: черновик — да, замена обсуждения с командой — нет. Практики формулируют то же самое жёстче: генерация хорошо закрывает рутину и плохо — приоритизацию и контекст, которого у модели просто нет.
В Shtab ассистент работает именно на этом шаге, после того как история уже написана человеком. Он может разбить задачу на подзадачи по её описанию с указанием нужного результата по каждой, добавить в задачу чек-лист для проверки, сформулировав пункты так, чтобы по каждому было понятно, пройден он или нет, найти в проекте дублирующие друг друга задачи с объяснением сходств и различий, установить зависимости между задачами по заданному порядку выполнения и оценить, что изменится в проекте при переносе срока — с проверкой зависимостей и списком затронутых задач.
Антипаттерн, который стоит проговорить прямо: запрос вида «напиши пользовательскую историю для функции Х» даёт правдоподобный текст без источника потребности, ровно то, что исследование Utrecht University называет нарушением критерия minimal. Рабочая последовательность обратная: сначала своя формулировка в две строки, основанная на реальном разговоре с пользователем, затем запрос модели на декомпозицию, чек-лист проверок и поиск дублей в проекте.
Что сделать на этой неделе
Что сделать на этой неделе
- Возьмите 10 последних карточек, которые возвращались на доработку, и отметьте для каждой, чего именно не хватало: роли, конечного результата или границы готовности. Через час станет видно, какая дыра повторяется чаще всего.
- Зафиксируйте стандарт в шаблоне карточки: описание — зачем и кому, чек-лист — критерии приёмки в формулировках «да/нет», подзадачи — части работы с исполнителями, пользовательское поле — источник потребности.
- Начните мерить два показателя: долю задач, вернувшихся на доработку после приёмки, и среднее время от статуса «готово» до «принято». Если через месяц они не сдвинулись, проблема не в формулировках карточек, а в том, что пользовательский путь так и не исследован.
Сам по себе формат истории не делает продукт лучше. Он убирает из приёмки спор о том, что имелось в виду. В командах, где такой спор случается на каждой второй карточке, это десятки часов в месяц, потраченных на выяснение, кто что понял неправильно.
Частые вопросы
Частые вопросы
Что такое история (story) в Agile простыми словами?
Это предмет разговора между заказчиком и исполнителем. Её задача — зафиксировать, кому и зачем нужна работа, прежде чем разбираться, как именно её делать.
Как сформулировать пользовательскую историю, если пользователь — внутренний сотрудник?
Так же, как для внешнего клиента, просто роль — это должность. Например: «Бухгалтер закрывает месяц без ручной сверки остатков, чтобы не задерживать отчётность на три дня».
Сколько критериев приёмки должно быть у истории?
Жёсткого норматива нет, но практики на Scrum.org сходятся на ориентире: больше 6–8 критериев — повод разделить историю на несколько.
Чем история отличается от варианта использования?
История описывает намерение и ценность в одном предложении, вариант использования — пошаговый сценарий со всеми ветками, включая ошибки.
Нужно ли писать истории для задач по техническому долгу?
Нет, для таких работ логичнее завести отдельный тип карточки с собственными полями.
Можно ли поручить написание историй нейросети?
Черновик и декомпозицию — да. Источник потребности — нет: причину «чтобы» модель не знает, она угадывает её по шаблону.
Что такое история (story) в Agile простыми словами?
Это предмет разговора между заказчиком и исполнителем. Её задача — зафиксировать, кому и зачем нужна работа, прежде чем разбираться, как именно её делать.
Как сформулировать пользовательскую историю, если пользователь — внутренний сотрудник?
Так же, как для внешнего клиента, просто роль — это должность. Например: «Бухгалтер закрывает месяц без ручной сверки остатков, чтобы не задерживать отчётность на три дня». Ценность тут не продажи, а снятая рутина.
Сколько критериев приёмки должно быть у истории?
Жёсткого норматива нет, но практики в обсуждении на Scrum.org сходятся на ориентире: больше 6–8 критериев — повод разделить историю на несколько, а не продолжать её расширять.
Чем история отличается от варианта использования?
История описывает намерение и ценность в одном предложении, вариант использования — пошаговый сценарий со всеми ветками, включая ошибки. Берите use case там, где важна точная последовательность действий, а не общий смысл.
Нужно ли писать истории для задач по техническому долгу?
Нет, для таких работ логичнее завести отдельный тип карточки с собственными полями. Выдумывать пользователя и ценность там, где их объективно нет, смысла не имеет.
Можно ли поручить написание историй нейросети?
Черновик и декомпозицию — да, это экономит время на рутине. Источник потребности — нет: причину «чтобы» модель не знает, она угадывает её по шаблону, а это ровно то, что ломает качество истории.
