Scrum — бэклог, приоритеты и оценка

ОБЯЗАТЕЛЬНО

Аналитику Руководителю

---

Один бэклог — один порядок

Product Backlog — единственный упорядоченный список того, что может понадобиться продукту. Product Owner отвечает за порядок с учётом:

• ценности для пользователя и бизнеса;
• рисков и зависимостей;
• стоимости задержки (что дороже не сделать сейчас).

Продукт может быть «гениальным», но без монетизации и фокуса компания остаётся дилетантской — приоритет PO включает выживание продукта, не только «красивые фичи».

Разделение:

Артефакт	Кто владеет порядком / содержанием
Product Backlog	PO приоритизирует
Sprint Backlog	Developers планируют выполнение

---

Refinement (уточнение бэклога)

До Sprint Planning элементы должны быть достаточно ясны (Scrum Guide: ready — обычно через ongoing refinement):

• понятны критерии приёмки;
• нет скрытых блокеров;
• команда может оценить относительный размер;
• ясно, какую ценность несёт элемент.

Шаблон user story и свойства требований — 7-04/111, 7-04/116.

---

Не оценивайте в часах (на уровне бэклога)

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

• «малый / средний / большой»;
• лучше — story points по шкале Фибоначчи: 1, 2, 3, 5, 8, 13, 21…

Относительные единицы в раннем Scrum

В ранних командах оценивали задачи условными единицами (например, «собаки» разного размера). Смысл тот же, что у points: сравнение с уже известными задачами, а не календарь.

Зачем Фибоначчи

Последовательность отражает растущую неопределённость крупных задач: разница между 8 и 13 «сжимает» ложную точность. Шкала Fibonacci в Planning Poker — распространённый компромисс, а не строгая математика.

Часы уместны для учёта факта и capacity отдельных ролей; points — для прогноза спринта и velocity.

---

Planning Poker

Метод (адаптация дельфийского подхода RAND, но быстрее):

1. Каждый получает карты Fibonacci.
2. PO (или аналитик) кратко объясняет элемент.
3. Все кладут карту одновременно (рубашкой вверх).
4. Если разброс ≤ 2 ступеней — берут среднее или консенсус.
5. Если разброс большой — объясняют крайние оценки (мин и макс) и повторяют раунд.

Плюсы:

• снижается давление «старшего»;
• всплывают разные допущения (как в примере с кухней: шкафы, кисть vs валик);
• оценивает команда, которая будет делать, а не внешний эксперт.

Подробнее в контексте аналитики — 7-04/116; оценка трудозатрат в управлении — 7-02/112.

---

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

На Sprint Planning:

1. PO предлагает Sprint Goal и кандидатов с верха бэклога.
2. Developers выбирают объём, исходя из velocity и capacity (отпуска, праздники).
3. Формируется Sprint Backlog и план работы.

Правило фокуса: не наращивать обязательства внутри спринта без отмены Sprint (редкое событие при резком изменении Product Goal).

---

Приоритеты vs multitasking

См. Потери: PO защищает команду от «всё срочно» — один явный фокус спринта. MoSCoW и другие техники приоритизации в аналитике дополняют, но не заменяют единый упорядоченный бэклог.

---

Что читать дальше

Тема	Ссылка
Velocity и спринт	./4
Внедрение с нуля	./7
Формализация требований	7-04/116

---