После приоритизации и спецификации backlog нужно понять, сколько это стоит по времени и сложности — иначе roadmap и commitment строятся на догадках. Совместная оценка трудоёмкости (joint estimation) — процедура, где BA, PM и команда реализации переводят уточнённые требования в согласованные оценки объёма с явными допущениями и рисками. Цель не в «точных часах в вакууме», а в общем понимании масштаба, на котором держатся план релиза, прогноз и управление ожиданиями стейкхолдеров.

Две заметки «02.05.02» в vault: change control (CCB) — 02.05.02 Управление изменениями (Change Control Board) (в оглавлении с префиксом -); переприоритизация backlog — 02.05.02 Управление приоритетами в условиях изменчивости. Не путайте ссылки.

1. Суть темы

Совместная оценка трудоёмкости требований — часть совместного управления требованиями (BA + PM) в разделе 02.05: согласованный процесс перевода элементов backlog (user story, use case, функциональное требование) в меры effort — story points, ideal days, человеко-часы или относительные размеры (T-shirt sizing).

Оценка — мост между спецификацией и планированием поставки. Роли в этой статье — в смысле раздела 02 (бизнес-анализ и совместное управление требованиями), а не полного системного анализа из ветки 03; см. 00.02 Бизнес-анализ vs Системный анализ vs Требования.

РольВклад в оценку
BAЯсность требований, граница scope item, критерии приёмки, зависимости, фиксация уточнений после сессии
PMГоризонт планирования, ресурсы, единицы измерения, forecast, связь с KPI, фиксация commitment
Product Owner (если выделен)Приоритет и scope на горизонте; на сессии — бизнес-контекст и trade-off, не подмена BA в спецификации
Dev / QA / архитектор / SAТехническая сложность, NFR, регрессия, интеграции, контракты API — см. 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)

Если оценивает один человек — PM «сверху» или lead «снизу» — возникает разрыв: «BA написал — команда не поняла — sprint сорван». Совместность снижает этот разрыв: оценка строится на общем прочтении требования, а не на интерпретации после факта.

Кто обязан на joint session: BA (или аналитик, ведущий пакет требований) и представители команды реализации (dev + QA по политике проекта) — без этого сессия не считается совместной. PM — для единиц, горизонта и фиксации результата; PO — когда решения по scope и Must/Should влияют на оценку или декомпозицию. Facilitator (SM, PM) — по модели команды.

Граница effort: на joint session команда обычно оценивает реализацию и верификацию элемента backlog — разработка, тестирование, интеграция, регрессия в рамках принятой политики (dev-only story points vs end-to-end с QA/DevOps). Работа BA до сессии (refinement, elicitation, подготовка пакета) и после (обновление спецификации, согласования) — отдельная строка в плане PM или учёт capacity аналитиков; не смешивайте её с SP команды без явной договорённости. Иначе «трудоёмкость требований» превращается в «оценку user story dev-командой», а KPI анализа теряют опору — см. 08.01 Метрики и KPI процесса анализа.

Граница темы:

Входит в 02.05.04Относится к соседним статьям
Процесс и роли BA + PM + команды при оценкеПриоритизация «что оцениваем» — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)
DoR, DoD и качество входа для оценкиФормат и полнота спецификации — 02.03.03 Спецификация требований (SRS, Use Case, User Story)
Инициация сессии, артефакты, re-estimationФасилитация и механика poker/Delphi — 02.02.02 Воркшопы, фасилитация и совместные сессии, 05.02 Scrum и Kanban (аналитик в Agile)
Assumptions, риски, пересмотр оценкиChange control и impact analysis — 02.05.02 Управление изменениями (Change Control Board)
Учёт блокеров в effort и calendar timeКарта зависимостей — 02.05.01 Управление зависимостями между требованиями
flowchart LR
    A[Приоритизированный backlog] --> B[DoR / уточнение BA]
    B --> C[Совместная сессия оценки]
    C --> D[Допущения и риски]
    D --> E[PM: план и прогноз]
    E --> F[Поставка и обратная связь]
    F --> B

Схема ориентирована на итеративный цикл refinement; при контрактной поставке (05.01 Waterfall и V-model) оценка и baseline фиксируются на вехах, re-estimation — через change control.

Ключевое различение: оценка (estimate) — прогноз с допущениями и диапазоном неопределённости; обязательство (commitment) — решение взять scope в конкретный спринт, релиз или контрактную веху.

КонтекстКто фиксирует estimateКто фиксирует commitmentКогда
ScrumКоманда на refinementКоманда на Sprint Planning; PO — scope и приоритет, PM — forecast и рискиКаждый спринт
Контракт / waterfallСовместная сессия + WBS bottom-upPM + стейкхолдеры на sign-off baselineПосле согласования SRS и плана
Масштаб SAFe / PIКоманды на team breakoutRTE/PM на PI PlanningНа горизонте PI — 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках

Смешивать estimate и commitment на одной встрече — типичный источник конфликта; PM отделяет forecast для стейкхолдеров от цифры, которую команда готова взять в работу. При re-estimation, сменившей масштаб работ, старый commitment не переносится автоматически: элемент снимают или переносят из sprint backlog, пока не согласованы новая оценка, приоритет и явное решение на planning / CCB.

2. Ключевые понятия

ПонятиеСуть
Трудоёмкость (effort)Ресурсы на реализацию элемента backlog в рамках явно названной границы: dev, QA, интеграция, документирование — по политике проекта; calendar time (ожидание вендора) — отдельно
Elapsed time / lead timeКалендарное время до готовности при внешних зависимостях; effort команды ≠ дата поставки
Объём / sizingМера «насколько велико» до декомпозиции: T-shirt, story points; на joint session BA+PM не проводят функциональный анализ точек (FPA) — это зона контрактной/финансовой оценки
Совместная (joint) оценкаСессия, где BA, PM и команда вырабатывают оценку на общем прочтении требований, AC и рисков
Относительная оценкаСравнение требований друг с другом (planning poker); менее чувствительна к «часам в вакууме»
Абсолютная оценкаЧасы, дни, стоимость; типична для WBS и контрактной поставки
Definition of Ready (DoR)Критерии допуска к оценке — минимум ниже; полнота качества — 02.04.03 Управление качеством требований
Definition of Done (DoD)Критерии завершения работы (регрессия, perf, security, документация); влияет на effort при тех же AC
Cone of uncertaintyРанняя оценка крупных блоков имеет высокую погрешность; декомпозиция и elicitation сужают диапазон
Assumptions & constraintsЯвные допущения — часть артефакта оценки, не только число
TraceabilityОценка привязана к ID и revision требования — 02.03.04 Трассировка требований (концепция)

Техники на joint session и где искать остальное

На совместной сессии чаще всего — planning poker / affinity (stories после DoR) и T-shirt / bucket sizing (epics, roadmap). Для waterfall и контракта — WBS bottom-up по элементам требований и deliverables спецификации, не декомпозиция по модулям кода из ветки 03. Analogous, PERT, Wideband Delphi и роли SM на poker — в 02.02.02 Воркшопы, фасилитация и совместные сессии и 05.02 Scrum и Kanban (аналитик в Agile).

ТехникаРоль BA + PM на session
Planning Poker / affinityBA — контент и уточнения; PM — единицы, горизонт, фиксация assumptions
T-shirt / bucket sizingBA — граница epic и unknowns; PM — диапазон forecast, без baseline «точной цифры»
WBS bottom-up (waterfall)BA — разбивка по требованиям и артефактам spec; PM — baseline, sign-off, связь с change control

WSJF из 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано) использует job size = последняя согласованная мера трудоёмкости на текущем горизонте: T-shirt на roadmap, story points после refinement. Менять единицу без пересчёта — ломать сравнимость; poker не обязателен для WSJF, но размер работы должен быть явно зафиксирован в журнале.

Definition of Ready и Definition of Done для оценки

Минимум DoR именно для допуска к оценке (расширенные критерии качества — 02.04.03 Управление качеством требований, 02.04.01 Верификация и валидация (V&V), 08.03 Тестирование требований (статическое тестирование)):

DoD проекта задаёт, что входит в «готово»: если DoD требует нагрузочное тестирование или security review, та же user story получит больший effort. Зафиксируйте DoD до сессии; иначе оценили dev, забыли QA и NFR из DoD.

NFR и cross-cutting в backlog оформляйте явно: отдельная story «hardening / perf / security» для epic, процент резерва на epic (политика PM) или чеклист NFR в DoR — не полагайтесь на «команда помнит».

Роли на сессии

РольДействия
BAОбъясняет бизнес-правила, in/out; фиксирует уточнения; после сессии обновляет спецификацию
PMГоризонт, единицы, политика dev-only vs end-to-end; commitment; contingency (buffer story vs risk reserve)
PO (опционально)Scope и приоритет при trade-off; не заменяет BA в разборе AC
SA / архитекторВопросы по интеграциям, контрактам, NFR — особенно при новых API
FacilitatorОбычно SM, PM или ротация; держит timebox — см. 02.02.02 Воркшопы, фасилитация и совместные сессии
КомандаДаёт оценку сложности; пробелы возвращаются BA

3. Как применяется в работе аналитика

Подготовка пакета к оценке

  1. Отбор элементов — из приоритизированного backlog только то, что попадает в горизонт (спринт, PI, релиз). Epics на roadmap — T-shirt sizing до декомпозиции.
  2. Пакет для команды — stories / use cases с AC, NFR, прототипы, открытые вопросы, dependencies. Оцениваем только верифицированный по политике пакет — 02.04.03 Управление качеством требований.
  3. DoR-check — элементы без DoR не оцениваются «для галочки»; refinement или spike.
  4. Граница «что оцениваем» — явно: миграция данных, регрессия, документация, мониторинг, работа BA после сессии — in scope оценки или отдельно.
  5. Политика effort — зафиксируйте: «5 SP = dev+QA по DoD» или «5 SP = dev, QA отдельно»; иначе сравнение оценок бессмысленно.
  6. Capacity аналитиков — PM и BA совместно закладывают refinement load: story-days BA на пакет vs SP команды на тот же горизонт; иначе «оценили 40 SP, а уточнить некому» — см. 08.01 Метрики и KPI процесса анализа.

Сценарий: PM просит цифру на квартал, декомпозиции нет

Epic или релиз без stories — типичный запрос roadmap. Действия BA:

  1. Зафиксировать границу scope и assumptions — 02.01.04 Определение границ решения (Scope Modelling).
  2. Дать диапазон (T-shirt или «M–L, ±50%») и явно запретить baseline как единственную точку.
  3. Перечислить unknowns и условия сужения (elicitation, spike, декомпозиция).
  4. PM коммуницирует диапазон стейкхолдерам; scope creep до уточнения — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.

Точная сумма SP «на весь квартал» без breakdown — не estimate, а forecast с высоким cone of uncertainty.

Проведение совместной сессии

Формат — воркшоп или часть Sprint Planning / refinement (05.02 Scrum и Kanban (аналитик в Agile)):

  1. Facilitator открывает сессию; BA зачитывает требование и AC; команда задаёт вопросы.
  2. Обсуждаются assumptions (технологии, объём тестов, feature flag, DoD).
  3. Команда даёт оценку; PM не давит на занижение на этапе estimate.
  4. При большом разбросе — остановиться: неясность фиксируется BA, spike или уточнение AC.
  5. PM фиксирует estimate, риски (08.05 Управление рисками на этапе анализа), elapsed time по external deps; commitment — на отдельном шаге (Sprint Planning, sign-off вехи).

Практические правила:

  • Оценивать маленькими порциями — декомпозиция по 04.02 Пользовательские истории (User Stories) и Job Stories; epic «в лоб» даёт иллюзию точности.
  • Расхождения в poker — пробел в спецификации, не спор «кто прав».
  • Отдельно оценивать spike, инфраструктуру, регрессию.
  • Contingency: padding «в голове» запрещён политикой — лучше explicit buffer story, risk reserve в PM или PERT с documented assumptions.
  • Velocity — инструмент PM для прогноза, не замена совместного понимания на сессии.

Сценарий: дорогая must-have после re-estimation

Оценили 13 SP вместо ожидавшихся 5; бизнес не снимает Must:

  1. BA и PM фиксируют delta effort и assumptions в журнале (новая revision / новый ряд).
  2. PM снимает или откладывает прежний commitment по этому ID в sprint backlog — пока нет нового planning-решения.
  3. PM инициирует пересмотр приоритетов backlog: defer, split scope, trade-off с другими Must.
  4. При material change — 02.05.02 Управление изменениями (Change Control Board); BA не «соглашается тихо» на нереалистичный commitment.

Артефакты после сессии

АртефактСодержание
Обновлённые требованияУточнения, новые AC, закрытые вопросы
Журнал оценкиID + revision, единица, значение или диапазон, граница effort (dev/e2e), дата, участники
Assumptions logТехнологии, объём регрессии, DoD, external lead time
RisksTechnical/business риски на effort или calendar
Связь с планомPM: forecast, capacity, dependency dates

Оценку привязывайте к ID — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence), 10.01.15 Шаблон матрицы трассировки.

Пересмотр оценки и версионирование

BA инициирует re-estimation при: change scope или NFR; spike/research; изменении зависимостей или external blocker; scope creep — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.

Правило baseline в журнале: запись остаётся валидной только для пары ID + revision (или версии спецификации), на которой проводилась сессия. Изменение AC, влияющее на effort — новый ряд в журнале и новая revision; косметика формулировок без смены scope — комментарий к существующей записи, re-estimation не обязателен. При сомнении — короткая проверка с командой: «понимание то же?»

Impact analysis включает delta effort, elapsed time и влияние на приоритеты backlog. Формальный путь — 02.05.02 Управление изменениями (Change Control Board).

Пример фрагмента журнала оценки

IDRevКраткое описаниеОценкаГраница effortAssumptionsРиски
US-1421.2Экспорт заказа в PDF5 SPdev+QA по DoDШаблон PDF есть; без локализацииРегрессия отчётов — out of scope
US-1431.0OAuth2 для партнёров13 SP + spike 3 SPdev+QASpike: IdP; BA refinement 2d — отдельно в планеExternal: контракт IdP, lead time до Q2
EPIC-080.3Модуль аналитикиL (T-shirt)sizing onlyДекомпозиция в Q3; +15% NFR buffer на epicNFR perf не проработаны

Уровни детализации и cone of uncertainty

На этапе моделирования границ — диапазоны и относительный порядок. После спецификации и refinement — story points или часы для ближайшего горизонта. Точные часы для epics на старте — нарушение природы неопределённости; PM коммуницирует диапазон.

4. Типовые ошибки и ограничения

Ограничения

  • Оценка не заменяет elicitation: при сырых требованиях любая цифра — догадка.
  • Story points не сравнимы между командами и stream одного backlog; часы зависят от skill mix и техдолга.
  • Effort ≠ calendar: интеграция с вендором может добавить 0 SP и 6 недель ожидания.
  • Давление сроков искажает оценки — см. 01.07 Когнитивные искажения и критическое мышление; PM отделяет estimate от commitment, 09.07 Управление ожиданиями заказчика.
  • На ранних стадиях — только диапазоны, не точные даты релиза.
  • Оценка не гарантирует срок: forecast на velocity, capacity и external lead time.
  • Распределённые команды: async poker и чат теряют «общее прочтение»; фиксируйте assumptions письменно, для спорных items — короткий sync или отложенная оценка до уточнения BA.

Типичные ошибки

ОшибкаПоследствиеКак избежать
Оценка без dev/QAЗанижение NFR и тестированияJoint session; DoD в assumptions
BA ставит часы «для отчёта» без session и DoRЛожный baseline, конфликт на planningТолько совместная оценка или явный диапазон «draft, не baseline»
Не названа граница effort«13 SP» без dev/e2e — разные прочтенияПолитика на старте проекта
BA-работа «внутри» SP командыДвойной учёт или провал capacity аналитиковBA effort отдельно в плане PM
Смешение estimate и commitmentКонфликт со стейкхолдерамиРазные шаги; снятие старого commitment при re-estimation
Epic без декомпозицииИллюзия точности в roadmapT-shirt до breakdown
NFR «по памяти»Перерасход на perf, securityОтдельные items или buffer на epic
External deps только в SPНеверный forecastElapsed time в журнале
Не обновлять после change ACScope creep без перепланированияНовый ряд журнала — 02.05.05 Жизненный цикл требования
BA не фиксирует договорённости«Что оценили» ≠ «что сделали»Протокол, обновление спецификации
Скрытый paddingПотеря доверия к оценкамExplicit buffer или risk reserve

Mitigation: DoR + DoD, timebox на outliers, documented assumptions, регулярный refinement. При давлении «оценить меньше» — эскалация через PM и переговоры с техническими командами.

Критерий зрелости: для любого оценённого ID за пять минут — AC, revision, assumptions, граница effort, участники, дата; команда подтверждает, что цифра отражает то, что понимали. Иначе оценка декоративна.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

Статьи и справочные материалы