Уточнення Беклогу Продукту: 14 основних принципів

Product Backlog refinement (уточнення Беклогу Продукту) — постійний процес, що дозволяє скрам-команді планувати Спринти з урахуванням ситуативних змін. Ця історія — про розуміння всіма членами команди Why, What, How і Who (Чому, Що, Як і Для кого), враховуючи майбутню роботу над досягненням Цілі Продукту. Як результат, уточнення Беклогу Продукту є критично важливим фактором його успішності, оскільки воно різко підвищує здатність команди регулярно доставляти цінні Інкременти.

🎓 Розвивайте своє розуміння практики фасилітації та прийняття рішень, відвідавши тренінг Professional Scrum Facilitation Skills

Мета уточнення Беклогу Продукту, згідно зі Скрам Гайдом

Scrum Guide кілька разів згадує уточнення, пов’язане з управлінням Беклогу продукту та плануванням спринту.

Уточнення Product Backlog — це безперервний процес створення функціональних продуктових беклогів, що дозволяє команді Scrum без підготовки розпочинати планування спринту.

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

Ця компетенція критично важлива для формування довіри стейкхолдерів та менеджменту до команди, яка регулярно постачає цінні Інкременти.

Незважаючи на те, що уточнення по часових рамках зникло зі Scrum Guide 2020, у командах зберігається правило резервувати до 10% часу на уточнення Беклогу Продукту.

Структурувати процес Product Backlog refinement варто довкола таких питань:

• Які елементи втратили релевантність?
• Які елементи потрібно поділити?
• Які елементи потребують оновлення інформації/вимог?
• Чи впливає це оновлення на попередні оцінки?
• Чи не змінилася пріоритетність елементів беклогу?
• Чи маємо ми щось нового до врахування? (Якщо так, це нове записується в якості нових елементів продуктового беклогу).

На мою думку, наступна цитата Карла Поппера чудово описує, чому уточнення Беклогу Продукту є настільки важливим фактором успіху будь-якої скрам-команди:

14 принципів успіху в Product Backlog Refinement

1. Мета уточнення
   Кінцевою метою уточнення є спільне розуміння “чому”, “що”, “як” і “для кого” у парі з упевненістю розробників у тому, що вони можуть створити відповідний елемент Backlog Product протягом одного спринту.
2. Тривалість
   Уточнення єдиного елементу беклогу може мати кілька раундів. Краще проводити їх швидко, але часто.
3. Постійне уточнення
   Не потрібно ставитися до уточнення Беклогу Продукту як до ізольованої годинної події, яку потрібно виконувати в рамках якогось чеклісту. Уточнення потрібно проводити тоді, коли членам команди потрібно уточнити той чи інший елемент беклогу. Наприклад, коли вони отримали нову інформацію. Ставтеся до цього як до регулярної події, що є частиною роботи команди під час спринту.
4. Не обов’язково, щоб усі були присутні
   Не витрачайте час команди. На уточненні мають бути присутні лише ті члени команди, які безпосередньо працюють над цим елементом Беклогу або зацікавлені в його просуванні.
5. Уточнення для всіх
   Product Owner має намагатися залучити всю скрам-команду до процесу уточнення Беклогу Продукту, щоб вони не покладалися лише на головного інженера і дизайнера. Інклюзивний підхід має очевидні переваги, адже при вирішенні комплексних проблем не існує експертів, а тільки конкуруючі ідеї. Таким чином, обмежуючи кількість учасників уточнення Беклогу Продукту, ми підвищуємо ризик виникнення підтверджувальних упереджень.
6. Аутсайдери
   Запрошуйте стейкхолдерів і експертів у темі на сесії уточнення, так ви розширите розуміння проблеми і спектр можливих рішень.
7. Визначення готового
   Визначення готового представляє або тимчасові тренувальні колеса для молодшої команди Scrum, або антипатерн.
8. Не уточнюйте сильно наперед
   Тримайте фокус продуктового беклогу на Цілі Продукту, приблизно покриваючи 3-6 Спринтів. Цей фокус дозволить вкладати в уточнення мінімум зусиль, не марнуючи час команди. Уточнюйте лише ті елементи Беклогу, які точно або майже точно підуть у розробку найближчим часом.
9. User research
   Уточнення беклогу і аналіз продукту близько пов’язані і відбуваються паралельно. User research — це частина активностей уточнення Беклогу і включає, наприклад, юзер інтерв’ю, розробку прототипів і їх тестування на користувачах.
10. INVEST
    Уточнюючи елементи Беклогу Продукту, слідуйте за принципом INVEST, популяризованим Білом Уейком. I – Independent (незалежний), N – Negotiable (відкритий для переговорів), V – Valuable (цінний), E – Estimable (оцінюваний), S – Small (маленький), T – Testable (відкритий для тестування).
11. Визначення і критерії готового
    Product Backlog refinement вимагає пропрацьованого визначення готового. Більше того, потрібно розуміти різницю між визначенням готового і критеріями готовності, а також дійти спільного розуміння того, як команда використовує те й інше.
12. Якість
    Враховуйте технічний борг і рефакторинг, уточнюючи елементи Беклогу, адже те й інше є постійними “викрадачами часу” в розробників, що можуть з легкістю відкусити 15-30% капасіті.
13. Оцінка
    Завершувати уточнення оцінюванням має зміст тоді, коли ви вирівняєте цифри. Оцінка елементів Беклогу Продукту наприкінці уточнення слугує єдиній меті: щоб команда розуміла всі “що”, “чому” і “як”. Іншими словами, щоб була точка дотику, від якої всі члени команди зможуть рухатися вперед. Розбіжності під час оцінювання можуть вказувати на відмінності в розумінні природи елемента Беклогу продукту. Або вони можуть вказувати на прогалини в навичках, які команда, ймовірно, повинна вирішити. У будь-якому випадку ці проблеми підвищують ризик невиконання результатів у майбутніх спринтах. Коли ваша команда Scrum вирішить зробити оцінку частиною процесу уточнення, дотримуйтеся відносності у цих оцінках — сторі пойнтах, футболках, папугах — і уникайте абсолютних оцінок. Вони йдуть корінням в індустріальну епоху та тейлоризм, пов’язані з індивідуальною продуктивністю, ефективністю, винагородою та жорсткими зобов’язаннями. Крім того, ставити абсолютні оцінки люди так само не вміють.
14. Не все є юзер сторі
    Не станьте жертвою фетишу формату сторі: “Як адмін баз даних, я хочу оновити ПЗ бази даних до версії 5.x, щоб….” Історії користувачів описують майбутній стан системи з точки зору користувача. Отже, хоча кожна історія користувача є елементом Беклогу продукту, не всі елементи Беклогу продукту є історіями користувача. Існують інші робочі елементи, як-от баги, спайки або нефункціональні вимоги, згадані вище. Уникайте марнування часу на примусове використання під час уточнення уніфікованого формату елементів Backlog Product. Крім того, уточнення стосується домовленостей між членами команди. Річ не у виборі правильного формату документації.

Висновки

Уточнення Беклогу Продукту – це безперервний процес створення дієвих продуктових беклогів. Ця компетенція скрам-команди є критично важливою для побудови довіри менеджменту і стейкхолдерів, адже вона дозволяє команді регулярно постачати цінні Інкременти. Також уточнення є надзвичайно ефективним способом зниження ризиків у складному середовищі.

Джерело: Стефан Уолперс