Як оцінювати задачі в story points: шість прикладів
Від простого поля до імпорту каталогу: розбираємо, що стоїть за оцінками 1, 2, 3, 5, 8 і 13 та як домовитися про обсяг роботи.
На оцінюванні команда бере задачу «додати експорт товарів у CSV». Один розробник обирає 3, інший — 8. Перший уявляє завантаження поточної сторінки таблиці. Другий — вивантаження всього каталогу з перевіркою прав і великим обсягом даних. Перш ніж обирати число, їм потрібно домовитися, яку саме задачу вони оцінюють.
Story points — це умовні бали для порівняння обсягу роботи всередині команди. Оцінка враховує зусилля, складність і невизначеність. Цей підхід описаний у поясненні Atlassian про оцінювання. На практиці важливо вміти пояснити: чому ця задача більша або менша за вже знайому?
Розберімо шість прикладів для вигаданої команди, яка розробляє кабінет керування інтернет-магазином. Усі числа нижче умовні: це зразок аргументації, а не готовий норматив для вашого беклогу.
З чого почати: задача-еталон на 2 бали
Команда вже додавала необов’язкове текстове поле до картки товару. Використала готову форму й API, обмежила довжину тексту, обробила помилку збереження та перевірила результат. У її шкалі така задача отримала 2 бали.
Тепер це еталон — завершена задача, яку команда пам’ятає та використовує для порівняння. Він допомагає ставити предметні питання:
- Чи можемо знову використати готові компоненти й API?
- Чи з’являються нові правила доступу або перевірки даних?
- Чи зачіпаємо інші частини продукту?
- Що потрібно перевірити, перш ніж вважати роботу завершеною?
Якщо спільного досвіду ще немає, візьміть добре зрозумілу задачу як тимчасовий еталон. Після її виконання перегляньте початкові припущення. Не потрібно вгадувати «правильну двійку» до початку роботи.
Приклади задач на 1, 2, 3, 5, 8 і 13 story points
У нашої команди вже є таблиця товарів, типові форми, перевірки прав і сервіс фонових завдань. Оцінки включають реалізацію, рев’ю та тестування, потрібні для готового результату.
| Бали | Приклад задачі | Межі роботи й причина оцінки |
|---|---|---|
| 1 | Додати пояснення до порожнього списку товарів | Текст погоджений, компонент готовий. Завантаження даних і поведінка сторінки не змінюються |
| 2 | Додати необов’язкове поле «Артикул постачальника» | Наявні форма й API підтримують додаткове поле. Потрібні обмеження довжини, збереження та обробка помилок; це еталон команди |
| 3 | Додати фільтр «У наявності» | API вже вміє фільтрувати товари. Треба узгодити фільтр із пагінацією, скиданням умов і порожнім результатом |
| 5 | Дозволити масово змінювати категорію вибраних товарів | Використовуємо наявне пакетне оновлення. Додаємо вибір товарів, перевірку прав і зрозумілий результат, якщо частина змін не збереглася |
| 8 | Експортувати весь відфільтрований каталог у CSV | Потрібні фонове формування файла, обмежений доступ до завантаження та обробка збоїв. Сервіс завдань готовий, але такого експорту ще немає |
| 13 | Імпортувати каталог із довільного CSV | Різні назви колонок, дублікати, некоректні значення й повторний запуск створюють забагато відкритих питань. Команда вирішує звузити вимоги й розділити роботу |
Цифри мають сенс разом з умовами. Якби API не підтримував фільтрацію, задача на 3 включала б додаткову роботу. Якби безпечний експорт уже був готовим модулем, задача на 8 могла б бути меншою.
Різниця між 3 і 5 не означає рівно два додаткові екрани чи певну кількість годин. Команда порівнює роботу в цілому.
Розбір експорту: звідки беруться оцінки 3 і 8
Повернімося до початкового прикладу. Учасники оцінювали різні результати:
| Питання | Версія на 3 бали | Версія на 8 балів |
|---|---|---|
| Які товари потрапляють у файл? | До 50 рядків поточної сторінки, уже завантажених у браузер | Усі товари, що відповідають фільтру, з погодженим лімітом обсягу |
| Де формується файл? | У браузері з уже доступних полів | На сервері у фоновому завданні |
| Що з правами доступу? | Використовуємо дозволені для перегляду дані; право експорту підтверджене | Перевіряємо право експорту та доступ до готового файла |
| Що бачить користувач у разі збою? | Помилку й можливість спробувати знову | Стан завдання та можливість повторного запуску без видачі неповного файла |
Це два умовні варіанти реалізації для конкретного продукту. Навіть невеликий експорт потребує погоджених правил доступу й коректного формату CSV.
Команда вирішує, що користувачам потрібні всі товари за поточним фільтром. Після уточнення обсягу вона оцінює саме цей варіант. Середнє між 3 і 8 не відповіло б на головне питання — який результат потрапить у реліз.
Що записати в задачі перед голосуванням
Замість короткого «зробити експорт» підготуйте опис, із яким можна працювати. Наприклад:
Результат: менеджер магазину завантажує товари за поточним фільтром, щоб передати список колезі.
Обсяг: усі відповідні товари, до 10 000 рядків; фіксовані колонки — назва, артикул, категорія та залишок.
Умови: експорт доступний лише ролі з відповідним дозволом; готовий файл доступний лише користувачу з дозволом на цей експорт; у разі збою користувач бачить помилку й може повторити запит.
Поза межами: автоматичне надсилання за розкладом і довільний вибір колонок.
Порівняння: більше роботи, ніж у масовій зміні категорії, через створення й зберігання файла та перевірку його доступності.
Уточнення перед оцінкою: перевірити, чи витримує наявний сервіс завдань погоджений обсяг. Відповідальний — розробник, який підтримує цей сервіс.
Ліміт у цьому прикладі — умовна вимога вигаданого продукту, а не рекомендоване значення для будь-якого експорту. Ваш опис має містити власні обмеження.
Якщо відповідь на відкрите питання може суттєво змінити реалізацію, спочатку отримайте її. Після цього команда зможе порівняти задачу з еталонами й обрати оцінку.
Що робити із задачею на 13 балів
У прикладі з імпортом проблема починається зі слова «довільного». Воно приховує багато різних форматів і правил обробки даних.
Першою корисною частиною може бути імпорт нових товарів за одним заздалегідь визначеним CSV-шаблоном: без оновлення наявних записів, але з перевіркою даних, погодженим правилом для дублікатів і зрозумілим звітом про помилки. Повторний запуск має поводитися передбачувано вже в цій версії.
Оновлення наявних товарів і налаштування відповідності колонок можна розглянути окремо. Після поділу команда оцінює кожну задачу заново. Сума оцінок не зобов’язана дорівнювати 13, адже вимоги стали точнішими.
Запитання, які виникають під час оцінювання
Чи входять тестування та рев’ю в story points?
У наведеній шкалі — так. Команда оцінює роботу до готового результату. Якщо врахувати тільки написання коду, порівняння з іншими завершеними задачами втратить частину змісту. Перед оцінюванням домовтеся, що означає завершена задача: які перевірки й рев’ю вона має пройти.
Що робити, якщо розробник і QA бачать різний обсяг?
Попросіть назвати конкретні сценарії. Наприклад, розробник врахував успішний імпорт, а QA — ще дублікати й повторне завантаження файла. Зафіксуйте, які сценарії входять у задачу, та оцініть її повторно. Оцінка має враховувати роботу всієї команди.
Чи потрібно збільшувати бали, якщо задачу виконує новачок?
Зберігайте порівняння на рівні командної роботи. Зміна виконавця сама по собі не змінює вимоги до задачі. Потребу в допомозі, навчанні та доступний час наставника обговоріть під час планування.
Як пояснити замовнику строк, якщо бали не дорівнюють годинам?
Говоріть про прогноз виконання з урахуванням досвіду команди, її доступності й залежностей. Саме число 5 не обіцяє конкретної дати. Окремо назвіть умови, за яких прогноз може змінитися.
Спробуйте шкалу на своєму беклозі
Візьміть одну завершену задачу-еталон і дві-три наступні задачі. Запишіть, чим вони відрізняються за обсягом, перевірками та невідомими. Якщо для порівняння бракує вимог, почніть з уточнення.
Коли задачі зрозумілі, створіть кімнату Planning Poker в Agilo і проведіть оцінювання з командою. Порядок голосування й роботу з розбіжностями знайдете в покроковому гайді, а можливості інструмента — на сторінці Agilo Planning Poker.
