Правила Planning Poker: про що домовитися команді
Практичний довідник про участь, незалежне голосування, перервані раунди та розбіжності, яких не усунути вибором числа.
Базові правила Planning Poker: оцінювати однаковий обсяг роботи, обирати картки незалежно, відкривати їх разом і перед записом результату обговорювати причини різних оцінок. Домовтеся, хто голосує та коли варто зробити паузу, а не вимагати число.
«Це ж на двійку, правда?» Одна репліка — і незалежне голосування вже під питанням. Той, хто думав про вісімку, тепер має сперечатися з готовою відповіддю, навіть не показавши картки. Кілька спільних правил допомагають кожному спочатку подумати, а вже потім обговорювати оцінки.
Незалежний вибір карток і спільне відкриття належать до практики, яку описує Agile Alliance. Наведені нижче рішення для спірних ситуацій можна адаптувати з командою. А підготовка та повний план зустрічі є в покроковому гайді з Planning Poker.
У цьому довіднику
Коли за різними оцінками стоять різні вимоги
Вигадана команда оцінює задачу «Дозволити адміністратору скасувати ще не прийняте запрошення до робочого простору». На картках — 2, 2, 5 і ?. Розмова звучить так:
Учасник із
2: «Ми просто робимо наявне запрошення недійсним».Учасник із
5: «А якщо людина прийме його в ту саму мить?»Учасник із
?: «Якщо вона вже приєдналася, ми маємо її видалити?»
Якщо оголосити 2 переможцем, питання залишаться. Фасилітатор просить Product Owner розділити відкликання невикористаного запрошення та видалення чинного учасника. Видалення стає окремою вимогою. Для скасування все ще потрібно визначити поведінку, коли прийняття та скасування відбуваються одночасно.
Раунд завершується питанням і відповідальним за його уточнення. Коли рішення зафіксують, команда зможе оцінити уточнену задачу. Фінального числа поки не потрібно.
Саме цю межу варто зберігати: голоси порівнюють розуміння роботи, але не визначають поведінку продукту. Числа в прикладі ілюстративні й не задають розмір функції запрошень.
Правила перед голосуванням
| Правило | Що це означає на практиці |
|---|---|
| Оцінюйте один узгоджений обсяг | Усі мають бачити очікувану поведінку та межі задачі. Якщо обсяг змінився, попередні голоси стосуються попередньої версії. |
| Використовуйте одну одиницю та колоду | Визначте, що саме оцінюєте: story points чи іншу одиницю. Не допускайте, щоб частина команди рахувала години, а решта порівнювала відносний розмір. |
| Залучайте до оцінювання тих, хто виконуватиме роботу | Враховуйте компетенції, потрібні для завершення задачі. Посада чи досвід не дають більшої ваги голосу. |
| Обирайте незалежно й відкривайте разом | Не називайте бажане число, не опитуйте учасників уголос і не відкривайте картки, поки хтось іще обирає. |
| З’ясовуйте припущення за різними оцінками | Вислухайте аргументи низьких і високих голосів, потім інші суттєві зауваження. Меншість могла помітити пропущену роботу. |
| Визначте значення спеціальних карток | Запитання, пропуск оцінювання та прохання про перерву передають різні повідомлення. Жодне з них не є числовою оцінкою. |
| Домовтеся, як завершувати або зупиняти раунд | Запишіть оцінку, яку команда готова використовувати, або зафіксуйте рішення чи дослідження, потрібне до наступної спроби. |
| Повертайтеся до оцінки через нову інформацію | Зміна обсягу чи нове обмеження можуть вимагати переоцінювання. Бажання покращити число у звіті не змінює роботу. |
Для калібрування story points використовуйте власні завершені задачі. Приклади оцінювання у story points показують, як описувати їхні межі, а гайд про Фібоначчі пояснює проміжки між картками та вибір шкали. Ці правила не вимагають конкретної колоди чи фіксованого переведення балів у години.
Хто голосує та хто фасилітує
У Scrum за оцінювання розміру задач відповідають Developers, які виконуватимуть роботу. Це визначено в розділі Scrum Guide про Product Backlog. Йдеться про досвід, потрібний, щоб довести задачу до готового результату, а не лише про написання коду. Scrum не вимагає використовувати Planning Poker і не встановлює правил для його спірних ситуацій.
Наприклад, фахівець із тестування запитує: «А що має статися, якщо адміністратор втратить доступ під час операції?» Це питання потрібне для оцінювання задачі загалом. Воно не має перетворюватися на окрему оцінку QA, яку просто додають до балів фронтенду й бекенду.
Product Owner пояснює результат і допомагає визначити, що входить у задачу. Фасилітатор стежить, щоб ніхто не підказував оцінку. Жодна з цих ролей не дає додаткового голосу. Якщо людина також долучається до виконання роботи, проговоріть, у якій ролі вона оцінює, а не вирішуйте це лише за посадою. Цю відмінність описує Mountain Goat Software у рекомендаціях щодо участі.
До відкриття карток визначте, хто оцінює саме цю задачу. Спостерігач не зобов’язаний називати число лише для того, щоб у кімнаті проголосували всі.
Як діяти, коли раунд іде не за планом
Хтось обрав знак питання або пропустив оцінювання
«Я обрав ?, бо не знаю, чи старі запрошення мають залишитися чинними». Тепер є конкретне питання. З’ясуйте, якого контексту бракує, замість мовчки прибирати картку з результату.
Розрізняйте три повідомлення:
?: мені потрібна відповідь, щоб оцінити задачу.- Пропуск: я не даю оцінки цій задачі.
0, якщо він є у вашій колоді: числова оцінка зі значенням, яке погодила команда.
Пропуск — це не нуль і не мовчазна згода. Якщо він означає, що команді бракує важливих знань, зафіксуйте цю прогалину. Картка для перерви — окреме прохання зробити паузу.
Потрібного фахівця немає
«Фахівець із бази даних втратив зв’язок. Можемо оцінювати далі?» Якщо команда розуміє цю частину роботи — так. Якщо без його відповіді може змінитися спосіб реалізації, зафіксуйте питання й відкладіть оцінку. Відсутність не означає згоду.
Число прозвучало до відкриття
«Ну тут точно двійка». Зробіть паузу й поверніться до того, що входить у задачу. Дайте кожному ще раз обрати незалежно; якщо картки вже відкрили, почніть новий раунд. Перезапуск не змусить забути почуте число, тому прямо запросіть аргументи на користь іншої оцінки.
Після голосування змінилася вимога
«До речі, треба ще відкликати запрошення, надіслані минулого місяця». Це може бути корисним уточненням, але це нова інформація. Оновіть умови приймання перед новим оцінюванням. Попередній результат стосувався попереднього обсягу.
Голоси різні або хтось просить менше число
Знову п’ятірки й вісімки? Запитайте: «Яку роботу ви врахували, а решта могла пропустити?» Якщо всі описують ту саму задачу, поверніться до еталонних прикладів. Якщо вимоги різні — спершу узгодьте обсяг.
Наявний скриншот Agilo з вигаданими учасниками та англомовним інтерфейсом. Середнє 5,3 не пояснює причини розбіжності. Кнопка Revote дозволяє почати новий раунд, а команда вирішує, чи спочатку потрібне уточнення або інший крок.
«Потрібно зробити цього тижня, може, поставимо трійку?» — це питання про обсяг і пріоритети. З’ясуйте, що можна прибрати чи змінити: менша картка сама по собі не прибирає роботу.
Agile Alliance застерігає від примусового зближення оцінок. Люди можуть погодити число для роботи, навіть якщо особисто схиляються до різних карток. Спочатку вислухайте невирішені зауваження й зупиніться, якщо оцінка приховуватиме питання без відповіді. Ні середнє арифметичне, ні вибір найдосвідченішого учасника цього питання не вирішать.
Домовленість, яку можна скопіювати
Додайте текст у нотатки команди й заповніть місця у квадратних дужках. Він має бути достатньо коротким, щоб прочитати перед першим голосуванням. Це домовленості команди, а не налаштування, які інструмент забезпечує автоматично.
Колода та одиниця: [обрати]. Еталонні задачі: [посилання].
Цю задачу оцінюють: [люди та потрібний досвід].
Фасилітатор: [ім’я]. За продуктові питання відповідає: [ім’я].
Погоджуємо обсяг, обираємо незалежно й відкриваємо разом.
Не підказуємо бажане число до відкриття.
Слухаємо причини різних оцінок і невирішені зауваження.
? означає питання; пропуск — немає оцінки, це не нуль і не згода.
Межа обговорення: [час або умова зупинки].
Зміна обсягу означає оновлення вимог і нову оцінку.
Записуємо число, коли учасники готові використовувати цю оцінку.
Бракує контексту чи потрібного досвіду: питання → відповідальний → наступний крок.
Переоцінюємо через нову інформацію, а не заради бажаної суми.
Межа обговорення допомагає обрати наступну дію. Вона не встановлює дедлайн, до якого треба примусово погодити число. Переглядайте домовленість, якщо вона регулярно заважає участі або приховує невизначеність.
Використайте домовленість в Agilo
Збережіть правила в нотатках команди, а для голосування скористайтеся Agilo Planning Poker. Оберіть узгоджену колоду, тримайте оцінки прихованими до відкриття та починайте новий раунд, коли уточнення змінює задачу. У вбудованих системах Agilo є знак питання, картка для перерви та можливість пропустити оцінювання; як на них реагувати, команда має погодити сама.
Створіть кімнату Planning Poker, коли визначили учасників, обсяг і правила. Для підготовки та повного сценарію зустрічі поверніться до покрокового гайду для фасилітатора.
Джерела
- Agile Alliance: Planning Poker — базова практика та ризик примусового зближення оцінок.
- Офіційний Scrum Guide — відповідальність за розмір задач; Planning Poker не є обов’язковою практикою Scrum.
- Mountain Goat Software: Planning Poker — участь у голосуванні та значення спеціальних карток.
