Story points теряют смысл, когда задачу закрывают за 25 минут: что оценивать вместо трудозатрат

Что такое story point? Это относительная оценка усилий. Команда сравнивает новую задачу со знакомой и учитывает объём, сложность и неопределённость.

Майк Кон, автор книги об оценке Agile-проектов, включает в баллы риск и всю работу до готового результата. Тестирование и согласования остаются, когда код пишет ИИ-агент.

Planning poker помогает найти разницу в понимании. Если за большой оценкой скрывается неизвестная интеграция, разговор нужен. Спор о соседних баллах без новых сведений не меняет ни запуск, ни проверку.

Затраты на оценку тоже измеряют: число участников умножают на время обсуждения. Это время людей. Его нельзя напрямую сравнивать с календарной длительностью работы машины.

Scrum Guide относит размер к деталям уточнения задач и отдаёт оценку разработчикам, но не задаёт единицу story points. Цель работы и критерий готовности сохраняются при любом способе оценки.

Как оценивать трудозатраты, если агент работает быстро? Наш ряд на открытой странице машины собран по чат-хронике и слияниям PR. Это календарное время до результата.

Инженер ведёт машину агентов на vibecoding.ru. В выборку входят задачи по реплике владельца. Автономная работа конвейера исключена; длинные задачи включают ожидание просмотров и решений.

Своего клиентского кейса у нас нет: эти числа описывают машину на нашем сайте. Медиана не означает, что чужой проект примут за 25 минут.

В ряду нет первоначальных story points, поэтому он не доказывает плохой точности баллов. Он даёт повод проверить стоимость оценки коротких задач в вашей команде.

Размер PR тоже не говорит, что принесла задача. Другие замеры есть в статье об агентной разработке в цифрах, а сроки с учётом очереди требуют отдельного расчёта.

Что оценивать вместо трудозатрат? То, от чего зависит решение запустить задачу. Кто получит результат, какое неизвестное мешает начать и чем обернётся ошибка.

Ценность называют через доступный результат. У нас новое поле в ответе общей функции сломало страницы новостей. Нужно было вернуть читателю доступ к странице; название «поправить передачу полей» этого не объясняло.

Риск называют отдельно от размера. Маленькое поле на общей границе способно сломать страницы. Большая серия однотипных изменений с проверкой каждого результата может быть проще для приёмки.

Проверку выбирают до запуска. В нашем примере тесту понадобилось сверять ответ функции с объявленным форматом. Общую постановку задач ИИ-агенту разбирает отдельная статья.

Неизвестное сначала превращают в исследование. У задачи «найти причину ошибки ответа» есть проверяемый ответ. После него можно решать, как чинить.

Новая шкала баллов для риска тоже прячет смысл. Если ответ «затрагивает оплату» меняет проверку и участника приёмки, полезен этот ответ. Его не нужно сводить в общую оценку сложности.

Можно ли перестать обсуждать маленькие задачи? Короткой бывает реализация, а ошибка затрагивает весь продукт. Перед запуском надо назвать область проверки.

У общей функции надо проверить всех получателей результата. Тест на добавленное поле и проверка формата ответа отвечают на разные вопросы.

Зелёный тест одного места не подтверждает работоспособность остальных. Важно выяснить, где проверять новое поле и кто увидит его потерю. Балл риска не отвечает ни на один из этих вопросов.

Ответственный за приёмку остаётся у каждой задачи. Разделение проверки и ответственности за ошибки ИИ разобрано отдельно. Балл не заменяет разрешение на выпуск.

Как понять, что новое планирование работает? По меньшим затратам на оценку без роста переделок. Рон Джеффрис в 2019 году предлагал сместить внимание на небольшие изменения, которые приносят ценность.

Kanban Guide, май 2025, предлагает считать начатую и незавершённую работу, число завершённых задач, возраст текущих и время завершения. Команда определяет, что считает стартом и завершением.

Принятый результат считают по одинаковому правилу. «Агент написал код» и «пользователь получил изменение» задают разные границы замера. Поломку после выпуска учитывают как возврат.

Для пилота берут знакомую группу обратимых задач с проверками. Неизвестные интеграции и изменения оплаты не годятся для первого сравнения.

Ритуал снимают с выбранной группы, а обсуждение смысла сохраняют. Если переделок стало больше, причина важнее сэкономленных минут.

Как покупать разработку, если отдельная оценка стала дорогой? Один вариант предлагает подписка на агентную разработку: одна сумма в месяц вместо согласования цены каждой задачи.

На /services у подрядчика указано «Смета на каждую задачу», у подписки «Одна сумма в месяц». Для задач и правок указано «Без лимита». Это наше предложение на 7 октября 2026.

Владелец результата выбирает следующую задачу и принимает её по условленному признаку. Согласовывать балл ради выставления счёта за каждую правку не требуется.

Без лимита не означает всё одновременно. На странице услуги поток определён как одна задача в работе, следующая ждёт в очереди. Эту границу учитывают при покупке.

На /services указан средний срок задачи 48 часов. Наши 25 минут описывают работу над собственным сайтом. Подменять одно число другим нельзя.

Если непонятно, где задачи ждут людей, следующий шаг даёт тест для руководителя. Он помогает выбрать, что менять в работе отдела, прежде чем покупать ещё один инструмент.

1. Оставляйте обсуждение там, где оно меняет решение.

2. До запуска называйте ценность, неизвестное, риск и проверку.

3. Принимайте короткую правку по последствиям. Скорость не уменьшает цену ошибки.

4. Сравнивайте время оценки, ожидание и возвраты при одном критерии готовности.

5. Подписка без сметы на каждую задачу сохраняет очередь и приёмку.