Що таке беклог: живий список, а не смітник
Беклог — це впорядкований список роботи, яку команда ще не зробила, але вважає вартою уваги. У розробці продукту це не «довгий to-do», а єдине джерело правди: що саме покращує продукт, у якому порядку і навіщо. Якщо список не впорядкований і не оновлюється, він швидко перетворюється на архів ідей, з якого ніхто не бере роботу.
Слово працює в двох режимах. У повсякденній англійській backlog — це нагромадження недоробленого: черга заявок, борги, відкладені замовлення. У Scrum і Agile беклог продукту — навпаки, свідомий інструмент вибору: команда не «розгрібає хвіст», а щоразу вирішує, що дасть найбільшу цінність наступним кроком.
Нижче — як цей інструмент влаштований, чим беклог продукту відрізняється від беклогу спринту, як упорядковувати елементи, коли все здається важливим, і що робити, якщо список уже роздутий або команда його ігнорує.
Два значення одного слова — і чому плутанина шкодить
Етимологія тут не декорація. У 1680-х backlog означав велике поліно, яке клали в глибину вогнища, щоб жар тримався довше. Наприкінці XIX століття слово набуло переносного сенсу «запас на потім», а з 1930-х закріпилося як «заборгованість по замовленнях і невиконаній роботі». Саме цей побутовий зміст досі живе в словниках: Cambridge описує backlog як велику кількість справ, які мали зробити раніше і тепер мусите надолужити.
У продуктовій розробці значення змістилося. Беклог — це не борг і не докір команді. Це навмисно обмежений, постійно змінний список можливого майбутнього. Scrum Guide 2020 формулює це жорстко: Product Backlog — emergent, ordered list of what is needed to improve the product; єдине джерело роботи Scrum-команди. «Emergent» тут ключове: список не затверджують раз і назавжди. Він з’являється з навчання, відгуків користувачів, змін ринку і технічних відкриттів.
Плутанина двох значень дає конкретну шкоду. Керівник, який думає «беклог = хвіст недоробків», тисне на команду «закрити все». Product Owner, який думає так само, боїться викидати елементи — і список росте. Розробник сприймає кожен рядок як обіцянку клієнту. У результаті беклог перестає бути фільтром і стає контрактом, якого ніхто не підписував.
Корисне правило: якщо елемент потрапив у список лише тому, що «якось шкода викинути», це вже не беклог, а склад. Склад треба інвентаризувати. Беклог треба впорядковувати.
Як беклог насправді працює в команді
Механізм простіший, ніж здається з сертифікаційних схем. Є продукт і є обмежена пропускна здатність команди. Беклог стоїть між ними: з одного боку збирає потреби, ризики, баги, дослідження; з іншого — віддає команді лише те, що зараз варте слотів уваги.
Відповідальність за ефективне управління беклогом продукту несе власник продукту (Product Owner). За Scrum Guide це чотири дії, не «написати Excel»: явно сформулювати й комунікувати Product Goal; створювати й ясно пояснювати елементи; упорядковувати їх; робити список прозорим, видимим і зрозумілим. Зауважте формулювання: не «пріоритизувати», а упорядковувати. Порядок — це не лише «цінніше вище». Туди входять залежності, ризик, вартість затримки, потреба щось дізнатися, політичний контекст релізу. Два елементи з однаковою бізнес-цінністю можуть стояти в різному місці, бо один розблоковує другий.
Команда розробників не «отримує завдання згори». Вона витягує готові елементи під час планування спринту (у Scrum) або безперервно, коли звільняється слот (у Kanban). Різниця принципова. Push — «зробіть оце до п’ятниці» — ламає прогнозованість. Pull — «беремо стільки, скільки влізе в ціль ітерації» — зберігає фокус.
Між великим списком і короткою ітерацією стоїть уточнення беклогу (Product Backlog refinement). Це не окрема обов’язкова церемонія з таймером, а постійна робота: розбити великий елемент, додати опис, оцінити розмір, змінити порядок. Старі підручники ще пишуть «близько 10% ємності команди». У поточному Scrum Guide цього відсотка вже немає: уточнюють стільки, скільки треба, щоб на плануванні не доводилося винаходити вимоги з нуля. Практичний орієнтир лишається корисним: якщо на плануванні спринту команда півтори години з’ясовує, «а що взагалі малось на увазі», refinement не відбувся.
Ще один механічний принцип, який часто пропускають: беклог — єдине джерело роботи. Паралельні списки в чаті, у голові керівника, у «термінових» листах і в особистій дошці розробника знищують сенс артефакту. Якщо баг критичний — він має з’явитися в беклозі й витіснити щось інше. Якщо він з’являється «поза чергою» щотижня, у команди немає беклогу. Є черга переривань.
Що саме лежить у списку
Елемент беклогу продукту (PBI) — це не обов’язково користувацька історія. У живому списку зазвичай сусідять:
- користувацькі історії та дрібніші задачі, які дають цінність користувачу;
- епіки — великі шматки, які ще треба розрізати, перш ніж брати в спринт;
- виправлення дефектів;
- технічний борг: рефакторинг, міграція, погашена «кредитна» складність коду;
- спайки — обмежені в часі дослідження, коли команда не знає, як оцінити роботу;
- нефункціональні вимоги: безпека, доступність, продуктивність, відповідність регуляціям;
- інфраструктурні задачі, без яких наступні функції просто не стануть.
Якщо в беклозі лише «фічі для клієнта», команда системно недоїдає якість. Баги й технічний борг тоді приходять «збоку» і розносять плани. Здоровий список змушує робити trade-off відкрито: цей спринт — або новий фільтр у каталозі, або стабілізація оплати. Обидва пункти не влізуть, і це має бути видно стейкхолдерам, а не ховатися в кулуарах.
Product, Sprint і Release: три списки з різною логікою
Назви звучать як градація одного й того самого. Насправді це три різні контракти. Беклог продукту відповідає на питання «що взагалі може покращити продукт». Беклог релізу (його немає в Scrum Guide, але ним користуються продуктові команди) — «що має зібратися, щоб випустити версію». Беклог спринту — «що саме розробники планують зробити в цій ітерації, щоб досягти цілі спринту».
Офіційне визначення беклогу спринту з Scrum Guide складається з трьох частин: ціль спринту (навіщо), відібрані елементи беклогу продукту (що) і конкретний план, як доставити інкремент (як). Це план розробників і для розробників. Власник продукту не «призначає» його. Він пояснює порядок і ціль продукту; розробники прогнозують, скільки влізе.
| Параметр | Беклог продукту | Беклог релізу | Беклог спринту |
|---|---|---|---|
| Горизонт | Життєвий цикл продукту, постійно | Один реліз або квартал | Один спринт, зазвичай 1–4 тижні |
| Питання, на яке відповідає | Що може покращити продукт | Що входить у цю поставку | Що робимо зараз, щоб досягти цілі ітерації |
| Хто відповідає | Product Owner | PO разом із командою та стейкхолдерами | Розробники |
| Гнучкість | Висока: елементи щодня можуть з’являтися, зникати, змінювати місце | Середня: склад релізу стабілізують ближче до дати | План змінюють розробники, але ціль спринту бережуть |
| Рівень деталізації | Верх — готові історії, низ — начерки й епіки | Достатній, щоб зрозуміти обсяг поставки | Задачі на години або пів дня, з планом «як» |
| Що буде, якщо його заморозити | Продукт відстане від реальності користувачів | Реліз або зірветься, або вийде з зайвим | Команда втратить можливість адаптуватися всередині ітерації |
Джерело порівняння: Scrum Guide 2020 (product і sprint backlog) та практики release backlog, описані в гайдах Aha! і Atlassian Agile Coach.
У Kanban окремого «беклогу спринту» немає. Є вхідна черга, ліміти незавершеної роботи (WIP) і політика поповнення. Логіка та сама: не починати нове, доки не довели поточне. Різниця лише в ритмі витягування — без фіксованого вікна ітерації.
Багато команд тримають ще «особистий беклог» спеціаліста. Це нормально як чернетка. Це небезпечно як тіньова черга: людина бере «своє», ігноруючи порядок продукту. Якщо дизайнер два тижні шліфує екран, якого немає в топі списку, продукт не став кращим — просто хтось був зайнятий.
З чого складається елемент і як його довести до «готового»
Поганий елемент беклогу виглядає так: «Зробити особистий кабінет». Команда киває, бо слова знайомі, і через спринт з’ясовується, що замовник мав на увазі історію замовлень, маркетинг — збережені картки, а розробка — OAuth. Три тижні пішли на узгодження того, що мали узгодити до планування.
Класичний шаблон користувацької історії (формат Connextra, який популяризував Майк Кон) лишається робочим саме тому, що змушує назвати три речі:
Як [роль], я хочу [дію], щоб [отримати цінність].
Для сервісу онлайн-запису це може бути: «Як пацієнт, я хочу бачити вільні слоти лікаря на найближчі 14 днів, щоб вибрати час без телефонного дзвінка». Роль відсікає абстрактного «користувача». Дія відсікає «зробити зручніше». Цінність дозволяє поставити питання: а якщо слоти покажемо, але без часового поясу — цінність ще є?
Історія сама по собі ще не готова до спринту. Їй потрібні критерії приймання: конкретні умови, за яких PO скаже «так, це зроблено». Не «кабінет зручний», а «пацієнт бачить лише слоти свого відділення; минулі дати недоступні; при скасуванні з боку клініки приходить повідомлення». Без цього «готово» означає різні речі для дизайнера, тестувальника і власника продукту.
INVEST і DEEP — два фільтри різного масштабу
Для окремого елемента працює мнемоніка INVEST (Білл Вейк, 2003): Independent, Negotiable, Valuable, Estimable, Small, Testable. Історія має бути відносно незалежною, придатною до обговорення (це не контракт на 40 сторінок), цінною для стейкхолдера, оцінюваною, достатньо малою, щоб улізти в спринт, і принципово тестованою. Якщо елемент не оцінюється — зазвичай не вистачає розуміння, а не «складної математики». Тоді спочатку спайк на пів дня, а не епік на місяць.
Для всього списку працює інший фільтр — DEEP, запропонований Романом Піхлером і Майком Коном. Беклог має бути:
- Detailed appropriately — деталізований відповідно до місця. Верх списку розписаний до критеріїв приймання, низ може бути одним рядком. Деталізувати все «наперед» — найдорожчий спосіб марнувати час PO.
- Estimated — хоча б грубо оцінений, особливо те, що претендує на найближчі ітерації. Одиниця (story points, ідеальні дні, t-shirt sizes) менш важлива, ніж спільна шкала команди.
- Emergent — живий. Нові елементи з’являються, старі змінюються або помирають. Заморожений беклог на пів року — це камуфляж Waterfall.
- Prioritized / ordered — має явний порядок. «Усе важливе» означає «нічого не важливе».
Місток між INVEST і DEEP — Definition of Ready (DoR). Це домовленість команди: що має бути в елементі, перш ніж його взагалі можна брати в спринт. Типовий мінімум: зрозуміла цінність, критерії приймання, залежності названі, дизайн або макет є (якщо екранний інтерфейс критичний), оцінка є, обсяг влізає в спринт. DoR — не бюрократія ради бюрократії. Це запобіжник від ситуації, коли спринт починається з «ну, якось зробимо, розберемось».
Окремо варто відрізняти DoR від Definition of Done. Ready відповідає на «чи можна починати». Done — «чи можна вважати інкремент поставленим»: код у репозиторії, тести, рев’ю, документація, відповідність стандартам безпеки. Команди, які змішують ці два списки, отримують або параліч на вході, або «готово, але на проді не можна».
Як упорядковувати беклог, коли все здається важливим
Пріоритизація ламається не від браку фреймворків, а від політики. Відділ продажів хоче демо для великого клієнта. Підтримка тоне в тікетах. Маркетинг обіцяв лендінг «на наступному тижні». Техліду болить архітектура. Усі аргументи правдиві. Без явного правила виграє той, хто голосніше зайшов у Slack.
Фреймворк не замінює рішення PO. Він робить рішення видимим і повторюваним. Три найживіші підходи закривають різні питання.
MoSCoW розкладає елементи на Must / Should / Could / Won’t для конкретного вікна — релізу чи кварталу. Це не рейтинг, а кошики. Must без якого реліз не має сенсу. Should — болісно втратити, але продукт житиме. Could — якщо лишиться ємність. Won’t — свідома відмова саме зараз, не «ніколи в житті». Слабкість методу: Must розростається. Якщо в кошику Must опинилася половина беклогу, це вже не пріоритизація, а відмова обирати.
RICE (формула команди Intercom) дає число:
RICE = (Reach × Impact × Confidence) / Effort
Reach — скільки людей або подій зачіпає зміна за період. Impact — сила впливу на мету (часто шкала 0,25 / 0,5 / 1 / 2 / 3). Confidence — наскільки команда вірить оцінкам (100% / 80% / 50%). Effort — обсяг роботи в людино-спринтах чи story points. Сила RICE — у знаменнику: дешева зміна з середнім ефектом обходить дорогу «стратегічну» ставку. Слабкість — ілюзія точності. Якщо Reach узяли зі стелі, число лише маскує здогад.
WSJF (Weighted Shortest Job First) прийшов із економіки потоку Дона Райнертсена і закріпився в SAFe. Формула:
WSJF = Cost of Delay / Job Size
де Cost of Delay = цінність для бізнесу або користувача + критичність часу + зниження ризику чи відкриття можливості. Логіка жорстка: велика цінність, яка робиться пів року, може програти середній цінності, яку можна віддати за тиждень. Саме тому «найважливіший епік» часто не має стояти першим.
| Метод | Що добре вміє | Де просідає | Коли ставити в основу |
|---|---|---|---|
| MoSCoW | Швидко домовитися про склад релізу мовою бізнесу | Не ранжує елементи всередині кошика; Must роздувається | Коротке вікно поставки, багато стейкхолдерів, потрібен спільний словник |
| RICE | Порівняти різнорідні ідеї одним рахунком, врахувати невпевненість | Легко підкрутити цифри; погано ловить залежності й ризик | Продуктовий беклог фіч, є хоч якась аналітика охоплення |
| WSJF | Враховує ціну зволікання і винагороджує короткі джоби | Важко оцінити Cost of Delay без економічної дисципліни | Потік фіч на кількох командах, є відчутна вартість затримки (сезон, регулятор, контракт) |
| Матриця вплив / зусилля | Швидкий візуальний відбір «швидких перемог» | Все злипається в центр; ігнорує час і ризик | Ранній продукт, маленька команда, треба розігнати зворотний зв’язок |
Джерело: опис RICE — Intercom; WSJF — Scaled Agile Framework на базі ідей Д. Райнертсена; MoSCoW — класика бізнес-аналізу (DSDM).
У реальних кейсах часто працює зв’язка, а не один метод. MoSCoW відсікає те, чого не буде в цьому кварталі. Усередині Must/Should елементи ставлять у порядок через RICE або WSJF. Залежності й ризики PO все одно накладає руками: «оцінка висока, але без цієї інтеграції решта історій не поїде».
Практичний мінімум, якщо фреймворк ще не обрали: для кожного елемента з топу запишіть одне речення цінності, грубу оцінку зусиль і що станеться, якщо почекати місяць. Уже цей триптих прибирає половину «треба було вчора».
Помилки, міфи і «зомбі-елементи»
Найстійкіший міф: беклог — це специфікація, яку затвердили, отже команда винна, якщо щось з нього «не зробила». У гнучкій розробці незроблений низ списку — норма. Зробленим має стати те, що було вгорі й потрапило в спринт. Решта — гіпотези про майбутнє. Стейкхолдер, який цитує рядок річної давнини як обіцянку, не «правий по документах». Він користується мертвим артефактом.
Другий міф: що довший беклог, то багатший продукт. Навпаки. Піхлер прямо радить: якщо список став некерованим, його варто викинути, намалювати дорожню карту з фокусом на наступну продуктову ціль і зібрати новий DEEP-беклог. Сотні карток не додають опцій. Вони ховають опції.
Третій: PO пише беклог наодинці, а команда «оцінює і кодить». Уточнення — спільна робота. Розробник бачить технічний ризик, який PO не помітить. Дизайнер бачить, що «дрібна» історія ламає навігацію. Тестувальник бачить дірку в критеріях приймання. PO, який приносить на планування готові «ТЗ», отримує слухняну команду і поганий продукт.
Четвертий: у беклог не кладуть технічний борг, бо «користувач цього не бачить». Користувач бачить повільний чекаут, збої після релізу, тримісячну затримку наступної функції. Борг, який не стоїть у списку, все одно з’їдає ємність — просто ніхто не обирав це свідомо.
Окремий жанр — зомбі-елементи. Картка живе вісім місяців, ніхто її не бере, ніхто не видаляє, бо «раптом знадобиться». З практики команд, які ведуть Jira роками, такі картки накопичують коментарі, міняють виконавців і врешті втрачають автора. Ліки прості й неприємні: термін придатності. Якщо елемент не піднімався в топ за N спринтів і не прив’язаний до поточної Product Goal — архів або видалення. Ідеї не зникають: вони живуть у research-нотатках, у відгуках, у головах. Беклог — не музей.
Ще одна тиха помилка — змінювати склад поточного спринту щодня «бо клієнт попросив». Беклог продукту має бути гнучким. Ціль спринту — ні. Якщо термінове справді важливіше, спринт скасовують або переплановують явно, а не «тихенько підмішують» задачі. Інакше метрики швидкості брешуть, а команда вчиться не доводити роботу до Done.
Нарешті, антипатерн «беклог у локальному файлі, який PO надсилає раз на два тижні». Прозорість — частина визначення артефакту. Список, якого команда не бачить у момент роботи, не керує роботою.
Що робити, коли беклог уже роздутий або команда його ігнорує
Багато хто стикається з ситуацією, коли в трекері 400+ елементів, грумінг перетворився на читання роману, а на плануванні все одно беруть те, що «гаряче з чату». Це не моральна проблема дисципліни. Це сигнал, що артефакт перестав виконувати функцію фільтра. Нижче — три типові поломки і що з ними робити, не чекаючи «нового процесу з понеділка».
Список розрісся так, що його ніхто не читає
Не уточнюйте все. Розріжте беклог на три горизонти. Горизонт «зараз» — на 1–2 спринт вперед: історії з критеріями приймання, оцінкою, DoR. Горизонт «далі» — наближені епіки з грубою оцінкою і гіпотезою цінності. Горизонт «пізніше» — однорядкові ставки, прив’язані до Product Goal або свідомо позначені як icebox з датою перегляду. Усе, що не влізає навіть у «пізніше», видаляйте пакетом. Так, буде спротив. Спротив дешевший за вічний грумінг мертвих карток.
Паралельно поверніть продуктову ціль. Беклог без цілі — це меню без кухні. Питання «чи наближає цей елемент поточну Product Goal?» відсікає дивовижно багато «хороших ідей».
Команда ігнорує порядок і бере «цікаве»
Спочатку перевірте, чи порядок зрозумілий. «Пункт №3 важливіший за №7, бо так вирішив PO» — слабке пояснення. «№3 закриває блокувальник оплати, без якого новий канал продажів не запуститься наступного вівторка» — робоче. Якщо пояснення немає, ігнорування раціональне: люди захищають сенс своєї роботи.
Друга перевірка — чи можна взагалі брати верхні елементи. Якщо топ не Ready, команда логічно спускається нижче, де картки зрозуміліші. Це не саботаж. Це наслідок того, що PO не інвестував у refinement. Ліки: не брати в спринт те, що не пройшло DoR, навіть якщо стейкхолдер нервує. Один «порожній» день планування лікує швидше, ніж три зірвані спринти.
Третя перевірка — чи немає тіньової системи заохочень. Якщо премія за «закриті сторі» без огляду на порядок, беклог програє. Метрика має дивитися на інкремент до цілі продукту, не на кількість карток.
Усе змінюється швидше, ніж команда встигає робити
Тут беклог не зламаний — зламаний ритм рішень. Скоротіть спринт. Зменшіть обсяг Must. Виділіть явний буфер на баги (наприклад, окремий відсоток ємності), щоб «непередбачуване» перестало бути сюрпризом. Для потоку з постійними інцидентами чесніший Kanban: ліміт WIP, клас сервісу для blocker, поповнення беклогу, коли є вільний слот. Scrum із щоденним штурмом пріоритетів — це вже не Scrum, а тривога з церемоніями.
Якщо зовнішні стейкхолдери приходять із новими «критичними» вимогами щотижня, потрібен єдиний вхід. Один канал, один PO, одне правило: нова вимога витісняє щось із поточного порядку. Без витіснення нова вимога не існує. Це не грубість. Це захист пропускної здатності, яку інакше розмазують на нуль.
Короткий чек-лист «беклог ще живий»:
- команда може назвати продуктову ціль і показати, як топ-10 елементів до неї веде;
- верхні елементи проходять DoR без півгодинної розшифровки;
- баги й технічний борг стоять у тому самому списку, що й фічі;
- за останні два спринти щось видалили, а не лише додали;
- на плануванні майже не народжуються нові вимоги з нуля;
- стейкхолдери бачать порядок і розуміють, що «пізніше» — це рішення, а не образа.
Беклог поза IT і коли варто залучити фахівця
Сусіднє питання, яке з’являється одразу після «що таке беклог»: чи потрібен він, якщо ви не пишете код. Так, якщо є черга роботи, кілька замовників і обмежені руки. Маркетингова команда тримає беклог кампаній і експериментів. Операційна — чергу покращень процесу. Редакція — портфель матеріалів. Сенс той самий: не починати двадцять ініціатив паралельно й не тримати в голові «колись зробимо».
Відмінності теж є. У не-IT беклогах рідше працюють story points, частіше — класи сервісу (терміново / стандарт / можна почекати) і дедлайни зовнішнього календаря. INVEST корисний і тут: задача «запустити бренд» не Negotiable і не Small, доки її не розрізали на конкретні поставки. DEEP працює майже без змін: наступний тиждень розписаний, наступний квартал — ескіз.
Особистий беклог — окремий жанр. Це ближче до побутового значення слова: нагромаджені листи, недочитані вкладки, «треба б вивчити TypeScript». Йому допомагають не Scrum-церемонії, а жорстке обмеження незавершеного і регулярне видалення. Канбан з WIP = 3 часто чесніший за «спринт особистого розвитку».
Інструмент вторинний. Jira, Linear, Azure DevOps, YouTrack, Notion, фізична стіна зі стікерами — усі вміють тримати впорядкований список. Ламається не софт, а гігієна: дублі, відсутність єдиного поля порядку, п’ять дошок «для зручності», картки без власника змісту. Для команди до десяти людей інколи досить однієї колонки «Next» з явним верхом. Для кількох команд на одному продукті з’являється потреба в ієрархії епік → фіча → історія і в узгодженому WSJF. Масштаб змінює форму, не принцип.
Фахівець потрібен не тоді, коли «немає сертифіката Scrum Master». Він потрібен, коли конфлікт пріоритетів став політичним, PO фактично виконує роль секретаря стейкхолдерів, а не власника порядку, або коли технічний борг уже з’їдає більше половини ємності, але в списку його досі немає. Зовнішній коуч або досвідчений продакт не «наведе порядок у Jira». Він допоможе відновити єдине джерело роботи і правило витіснення. Без цих двох речей жоден шаблон беклогу не живе довше за два спринти.
Якщо ви тільки збираєте перший список, не починайте з фреймворку на 12 колонок. Зберіть двадцять реальних потреб користувача, викиньте десять, верхні п’ять розпишіть до критеріїв приймання, домовтеся, хто має право змінювати порядок, і зробіть список видимим команді. Це вже беклог. Решта — дисципліна його не зіпсувати.
Ключові інсайти
Беклог — не черга недоробків і не затверджене ТЗ. Це єдиний впорядкований список того, що може покращити продукт, з правом елементів з’являтися, змінювати місце і помирати. Product Owner відповідає за порядок і прозорість; розробники витягують готову роботу й володіють планом спринту. Деталізують лише вершину, оцінюють те, що близько, і регулярно видаляють зомбі.
Якщо з тексту лишити одну перевірку, нехай буде така: чи може команда зараз показати топ списку, пояснити, чому саме цей порядок, і взяти перший елемент без півгодинної розшифровки. Якщо так — у вас беклог. Якщо ні — у вас архів, і саме його, а не «мотивацію команди», треба лагодити першим.
