Story points и planning poker на собеседовании системного аналитика

Зачем спрашивают на собесе SA

Эстимация задач — обычная активность SA с командой. На собесе SA: «зачем story points», «как работает planning poker», «velocity vs man-days».

Что такое story points

Story points — относительная единица сложности задачи.

Учитывает:

• Объём работы.
• Сложность.
• Риск / неопределённость.

Не учитывает:

• Конкретные часы.
• Опыт конкретного исполнителя.

Логика: мозг человека плохо оценивает абсолютное время («2 часа»), но хорошо относительное («эта задача в 2 раза сложнее этой»). Story points используют это.

Шкала Фибоначчи

Стандарт — модифицированная Фибоначчи.

1, 2, 3, 5, 8, 13, 21, 40, 100

Почему именно она:

• Большая дисперсия на больших значениях отражает реальность («чем больше задача — тем менее точна оценка»).
• Меньше «середины» (между 5 и 8 нет 6 / 7) → меньше agonizing над выбором.

Семантика:

• 1 — тривиальная (правка строки).
• 2 — маленькая.
• 3 — средняя.
• 5 — большая.
• 8 — очень большая, риск.
• 13+ — слишком, разделить.
• 21, 40, 100 — обычно signal «не оцениваем, изучай дальше».

Команда калибрует свою шкалу относительно reference task'а.

Planning poker

Техника эстимации с участием всей команды.

Процесс:

1. PO / SA читает story.
2. Уточняющие вопросы (5 мин).
3. Каждый член команды выбирает свою оценку (карты 1, 2, 3, 5, 8, 13).
4. Все одновременно показывают.
5. Если расхождение — обсуждение (highest и lowest объясняют).
6. Повторная оценка — обычно сходится.
7. Финальное число — консенсус (обычно средняя или модальная).

Плюсы:

• Учитывает мнение всех — junior может видеть проблемы senior'у не очевидные.
• Обсуждение выявляет неясности в требованиях.

Минусы:

• Долго (на 20 stories — несколько часов).
• Иногда консенсус «давайте 5» без реального согласия.

Modern variants: async planning poker через Slack-боты, бессчётное голосование, t-shirt sizing.

Velocity и forecasting

Velocity — суммарные story points, закрытые командой за спринт.

Применение. Усреднение velocity за 3-5 спринтов → прогноз: «команда делает 35 SP в спринт».

Sprint 1: 32 SP
Sprint 2: 38 SP
Sprint 3: 35 SP
Sprint 4: 30 SP
Sprint 5: 40 SP
Avg: 35 SP

→ Если backlog = 175 SP, прогноз ~5 спринтов.

Внимание: velocity — внутренний инструмент команды для планирования. Не KPI и не сравнение между командами.

Альтернативы

T-shirt sizes. XS, S, M, L, XL, XXL. Грубее SP, проще для бизнеса.

Hours / man-days. Прямые часы. Проблема — точность псевдо-объективная (часы мы не оцениваем хорошо), плюс зависят от исполнителя.

No estimation. Бить задачи на «эквивалентные» (~1 day chunks), считать throughput. Подход Kanban.

Bucket estimation. Раскидать задачи по «корзинам» (1, 3, 5, 8) большой группой за 5 минут. Быстрее planning poker.

Антипаттерны

Story points как KPI. «Команда A — 30 SP / спринт, B — 50 SP — B лучше». Story points команд несравнимы. Неверная мотивация → инфляция оценок.

SP = часы. «5 SP = 1 день». Превращение в часы убивает идею относительности.

Планировать отпуска / праздники в SP. Это capacity, не SP.

Спорить долго. Если расхождение 5 vs 8 — обычно неважно. Брать средне или большее, идти дальше.

Запрашивать оценку без AC. Не понимая scope, оценка бессмысленна.

Обновлять SP после старта. Зафиксированный estimate важен для tracking. Если scope change — новая story.

Частые ошибки

Эстимация в одиночку. SP — collective estimate. Один человек не видит всех аспектов.

Brand new tech без spike. «3 SP» на интеграцию с незнакомым API — наивно. Сначала spike (research), потом эстимация.

Игнорировать риск. Большая неопределённость = больший SP, не «5 как обычно».

Не разбивать > 13. Эпики 21+ SP — это уже другая story. Декомпозиция.

Пытаться угадать velocity заранее. Velocity — измеряется по факту, не назначается. Первые 3 спринта команды — calibration.

Story points как часы для бизнеса. Бизнес слышит «3 — это 3 дня». Лучше не объяснять SP бизнесу — давать прогноз в неделях / спринтах.

Связанные темы

• Scrum vs Kanban для SA
• User Stories и Acceptance Criteria для SA
• Acceptance Criteria Given/When/Then на собесе SA
• Виды тестирования для SA
• Подготовка к собесу системного аналитика

FAQ

Сколько SP на спринт назначать?

Average velocity предыдущих 3-5 спринтов. Не больше capacity (учёт отпусков).

Можно ли работать без SP?

Да — Kanban не требует. Главное — fixed-size stories и измерение throughput.

Это официальная информация?

Нет. Статья основана на работах Cohn («Agile Estimating and Planning»), материалах Scrum.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.