Як провести Planning Poker крок за кроком

Planning Poker працює тоді, коли картки запускають корисну розмову, а не змушують команду вгадувати «правильне» число. Хороша сесія дає всім однаковий контекст задачі, зберігає незалежність думок до відкриття карток і використовує розбіжності, щоб знайти приховані припущення ще до початку спринту.

Нижче — повторюваний сценарій для фасилітатора, Product Owner або людини, яка відповідає за беклог, і учасників, що працюватимуть над задачами.

Зміст

• Короткий сценарій
• Підготовка беклогу й учасників
• Практичний план на 45 хвилин
• Калібрування та представлення задачі
• Голосування, відкриття карток та обговорення
• Повторне голосування, поділ або пауза
• Приклад із п’ятьма задачами
• Поширені помилки
• Чекліст фасилітатора

Короткий сценарій

Для кожної задачі:

1. Поясніть користувацький результат, межі та умови приймання.
2. Дайте команді поставити уточнювальні питання.
3. Попросіть кожного учасника незалежно обрати картку.
4. Відкрийте всі оцінки одночасно.
5. Якщо розбіжність суттєва, вислухайте аргументи найнижчої та найвищої оцінок.
6. Уточніть або розділіть задачу та проголосуйте ще раз.
7. Запишіть погоджену командою оцінку й переходьте до наступної задачі.

Planning Poker — це практика оцінювання, а не обов’язкова подія Scrum. Актуальний Scrum Guide залишає вибір способу оцінювання команді та наголошує на відповідальності людей, які виконуватимуть роботу.

До зустрічі: підготуйте задачі до розмови

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

Для кожної задачі команда має бачити:

• користувацький або бізнес-результат;
• що входить і явно не входить до обсягу;
• умови приймання або приклад очікуваної поведінки;
• відомі залежності, обмеження та системи, яких торкнеться зміна;
• відкриті питання, здатні змінити розмір;
• посилання на дизайн чи технічний контекст, якщо вони потрібні.

Не обов’язково прибирати всю невизначеність до оцінювання. Саме оцінка має допомогти її побачити. Водночас контексту повинно вистачати, щоб відрізнити невелику технічну деталь від невирішеного продуктового питання.

Оберіть одну шкалу до початку голосування

Багато команд використовують послідовність на кшталт Fibonacci: 1, 2, 3, 5, 8, 13, 21. Зі зростанням задачі проміжки між числами збільшуються, адже зазвичай зменшується й точність очікувань. Agilo також підтримує інші вбудовані шкали та власні набори карток.

Сприймайте story points як відносний розмір усередині конкретної команди. Оцінка 5 корисна тому, що команда розуміє її відмінність від власних 2 або 8. Це не універсальна кількість годин і не таблиця для перенесення оцінок між командами.

Запросіть потрібних учасників

Голосувати мають люди, які виконуватимуть роботу. Product Owner або відповідальний за беклог пояснює мету, пріоритет і компроміси. Фасилітатор стежить за послідовністю, дає простір тихішим учасникам і не дозволяє розмові перетворитися на торг за бажане число.

Для участі в кімнаті й голосування в Agilo потрібен акаунт. Створіть кімнату до зустрічі, оберіть систему оцінювання, додайте або імпортуйте перші задачі та завчасно надішліть запрошення.

Актуальний інтерфейс Agilo: вісім вигаданих учасників уже проголосували, але всі оцінки приховані до одночасного відкриття.

Практичний план на 45 хвилин

Використайте його як стартову точку й адаптуйте до кількості та складності задач.

П’ять добре підготовлених задач часто корисніші за п’ятнадцять поспішних голосувань. Якщо під час сесії команда постійно проводить довге продуктове дослідження, поверніть такі задачі до уточнення беклогу, а Planning Poker залиште для роботи, готової до оцінювання.

Крок 1. Калібруйтеся на знайомому прикладі

Почніть із нещодавно завершеної задачі, форму якої команда пам’ятає. Ви не переписуєте історію заради ідеального числа. Ви створюєте спільне порівняння: «Тут була одна зміна інтерфейсу, одна зміна API та відоме тестове покриття — для нас це 3».

За можливості використовуйте приклади тієї самої команди й продукту. Оцінка 5 мобільної команди не повинна означати те саме, що 5 платформної команди.

Крок 2. Представте одну задачу

Відповідальний за беклог за кілька хвилин пояснює результат і межі. Не подавайте запропоновану реалізацію як уже прийняте рішення. Розробники можуть побачити простіший шлях або залежність, що повністю змінить оцінку.

Корисний вступ може звучати так:

Авторизований користувач може експортувати поточний звіт у CSV. Ця задача враховує активні фільтри таблиці, але не включає заплановані експорти чи власне налаштування колонок.

Після цього дайте команді поставити питання. Якщо відповідь змінює обсяг, оновіть задачу до голосування.

Крок 3. Голосуйте незалежно й відкривайте картки разом

Кожен учасник обирає картку, не бачачи вибору інших. Приховане голосування зменшує прив’язку до першого числа, думки найдосвідченішої людини чи очікувань фасилітатора.

Відкривайте картки лише після завершення голосування. В Agilo це можна зробити вручну або автоматично після голосу всіх учасників — залежно від налаштувань кімнати. Фасилітатор також може використати таймер, щоб м’яко обмежити час на питання чи вибір картки.

Не підганяйте учасника, який обрав ?. Це корисний сигнал: можливо, бракує контексту, задача лежить за межами його досвіду або містить припущення, яке варто озвучити.

Крок 4. Обговорюйте розбіжність, а не кожне число

Якщо голоси зібралися біля сусідніх значень, може вистачити короткого підтвердження. Якщо розкид великий — наприклад, 3, 3, 5, 8, 13 — почніть з аргументів найнижчої та найвищої оцінок.

Ставте конкретні питання:

• Що входить у 13, але не входить у 3?
• Чи є залежність або сценарій помилки, якого інші не помітили?
• Чи всі оцінюють однакові умови приймання?
• Чи хтось припускає наявність інфраструктури, якої ще немає?
• Чи прибере основну невизначеність поділ задачі?

Мета — спільне розуміння. Після нього може з’явитися одна оцінка, але примусове вирівнювання карток без усунення причини розбіжності руйнує сенс вправи.

Коли один учасник обирає 3, а інший — 13: гарна новина — картки не зламалися. Команда щойно знайшла розмову, заради якої й зібралася. 😅

Актуальний інтерфейс Agilo після відкриття: розкид 3–8 запрошує порівняти припущення. Середнє 5,3 дає контекст, але не обирає фінальну оцінку автоматично.

Крок 5. Уточніть, розділіть або проголосуйте ще раз

Після обговорення оберіть один із трьох шляхів:

1. Повторне голосування. Задача зрозуміла, а нова інформація змінила погляд команди.
2. Поділ задачі. Велика оцінка виникла через кілька результатів або технічних етапів в одному елементі беклогу.
3. Пауза в оцінюванні. Спочатку треба вирішити продуктове питання, залежність або провести дослідження.

Agilo підтримує новий раунд голосування, але не обирає фінальну оцінку замість команди. Фасилітатор і учасники самі вирішують, яке значення відповідає їхньому спільному розумінню.

Крок 6. Запишіть результат і переходьте далі

Коли команда погодила оцінку, яку використовуватиме, збережіть її біля задачі й оберіть наступну, поки сесія зберігає темп. Якщо ви використовуєте інтеграцію Agilo з Jira, задачі можна імпортувати разом із контекстом і повернути вибрану оцінку після налаштування синхронізації.

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

Приклад: п’ять задач беклогу

Наведені значення належать одній вигаданій продуктовій команді з власними еталонними задачами. Це приклади ходу думок, а не універсальні правильні відповіді.

Розгляньмо задачу про віджети. Учасники з низькими оцінками уявляли лише компонування на комп’ютері. Учасники з високими додали мобільні жести, збереження порядку, доступність керування з клавіатури та міграцію чинних налаштувань. Середнє арифметичне не усунуло б цю різницю. Поділ зробив обсяг явним і створив дві змістовніші розмови.

Поширені помилки

Сприймати середнє значення як відповідь

Середнє може приховати два несумісні трактування. Спочатку обговоріть розбіжність. Фінальна оцінка має відображати зрозумілу роботу, а не зручний результат обчислення.

Дозволяти найдосвідченішому учаснику назвати число вголос

Після першої озвученої оцінки інші числа тяжіють до неї. Тримайте картки закритими до одночасного відкриття і просіть пояснення вже після незалежного голосування.

Обговорювати реалізацію до розуміння результату

Технічна розмова потрібна, але лише після того, як усі однаково зрозуміли мету задачі. Інакше команда може оцінювати різні продукти.

Вимагати оцінку від неготової задачі

Фраза «число потрібне сьогодні» не прибирає залежність. Зафіксуйте питання, призначте відповідального й поверніться після потрібного рішення.

Порівнювати людей або команди за story points

Story points — локальний інструмент планування. Перетворення їх на показник продуктивності заохочує завищення чисел і робить оцінки менш корисними.

Чекліст фасилітатора

До зустрічі:

• оберіть 5–8 найближчих задач;
• додайте умови приймання та потрібні посилання;
• створіть кімнату й оберіть набір карток;
• визначте, хто пояснює задачі та хто голосує;
• підготуйте одну знайому еталонну задачу.

Під час кожного раунду:

• не відкривайте картки, доки всі не готові;
• вислухайте аргументи крайніх оцінок, якщо розкид суттєвий;
• оновлюйте задачу, коли змінюються припущення;
• повторіть голосування, розділіть або поставте задачу на паузу замість примусового консенсусу;
• запишіть оцінку й відповідального за наступне уточнення.

Після зустрічі:

• переконайтеся, що оцінки видно в беклозі;
• розв’яжіть питання поставлених на паузу задач до планування спринту;
• змінюйте шкалу лише тоді, коли команда системно вважає її некорисною.

Проведіть цей сценарій в Agilo

Agilo Planning Poker зберігає контекст беклогу, незалежне голосування, одночасне відкриття карток, повторні раунди та вибрану оцінку в одній кімнаті. Ви можете додавати задачі вручну або імпортувати їх із Jira, використовувати вбудований чи власний набір карток і переходити до наступної задачі одразу після рішення команди.

Створіть кімнату Planning Poker, коли задачі та учасники готові.

Джерела та додаткове читання

• Agile Alliance: Planning Poker — базовий сценарій із незалежним голосуванням, одночасним відкриттям, обговоренням і повторними раундами.
• Офіційний Scrum Guide — актуальне визначення Scrum і відповідальності за оцінювання елементів Product Backlog.