Епіки, фічі, задачі

Усі рівні на одному екрані — і один епік, розкладений до задач

Ті, хто це шукає, зазвичай хочуть двох речей: що означає кожне слово і як виглядає справжній приклад. Ось обидві. Спершу рівні — для кожного розмір, хто вирішує і що його завершує. Далі один епік для інтернет-магазину зі сторінки про WBSWBSWork Breakdown Structure — обсяг проєкту у вигляді дереваДерево всього, що проєкт має створити, розкладене, доки кожен шматок не стане досить малим, щоб його оцінити й віддати одному власникові, — і, за визначенням, нічого, чого проєкт не створює. Діти мають складати рівно свого батька, і саме це робить його межею обсягу, а не списком задач.Докладніше в статті →Усі терміни, через рік після запуску, розкладений аж до задач однієї історії. Наступні розділи посилаються на його рядки за номерами.

1. 1.Фіча 1 — Повторне замовлення з історії

   1. 1.1Постійний клієнт бачить минулі замовлення, найновіші першими, кожне з кнопкою «Повторити»
   2. 1.2«Повторити» кладе в кошик кожен товар, який досі є в наявності
   3. 1.3Товар, якого немає, названо, і запропоновано заміну
   4. 1.4Ціну, що змінилася від минулого замовлення, показано до оплати

2. 2.Фіча 2 — Збережені кошики

   1. 2.1Зберегти поточний кошик під назвою
   2. 2.2Відкрити збережений кошик і перейти одразу до оплати
   3. 2.3Перейменувати або видалити збережений кошик

3. 3.Фіча 3 — Нагадування, лише якщо випереджальні показники зрушать

   1. 3.1Підписатися на нагадування, коли товар, який купують регулярно, імовірно закінчується
   2. 3.2Лист-нагадування відкриває вже заповнений кошик
   3. 3.3Відписатися одним натиском, прямо з листа

4. 4.Enabler 4 — Сервіс історії замовлень

   1. 4.1Історія клієнта з 500 замовленнями повертається менш ніж за 300 мс
   2. 4.2Замовлення, перенесені зі старого магазину, теж є — рядок 5.2 у WBS
   3. 4.3Спайк, два дні: чи може ERP віддавати залишок кожного товару в реальному часі? Результат: письмове «так» чи «ні»

Задачі є рівно в однієї історії: 1.2, тієї, що в поточному спринті. Команда написала їх на плануванні спринту приблизно за десять хвилин. Це план команди, тому вони не пронумеровані разом з рештою:

• Ендпоінт, що копіює рядки замовлення в кошик.
• Перевірка залишку для кожного рядка — на основі відповіді спайка 4.3.
• Правило злиття для непорожнього кошика: додати, а не замінити.
• Автоматизовані тести на три критерії приймання історії.
• Подія для дашборда, що рахує повторні замовлення, розпочаті з «Повторити».

Звідки ці слова — і чому «епік» має три розміри

Жоден стандарт цих рівнів не визначає. У Scrum Guide, який багато команд вважають джерелом, немає жодного з трьох слів. У ньому один вид елемента — Product BacklogBacklogупорядкований список того, що лишилосьУпорядкований список усього, що може бути зроблено, і найцінніше — згори. Ключове слово тут «упорядкований»: беклог, де все однаково важливе, є списком побажань і не полегшує жодного рішення.Докладніше в статті →Усі терміни item. Про план усередині спринту там сказано лише, що його «часто складають, розкладаючи Product Backlog items на менші робочі елементи тривалістю день або менше. Як саме — вирішують виключно Developers». Усе вище цього елемента й нижче нього — домовленості.

Домовленості прийшли з трьох місць. Extreme ProgrammingExtreme Programmingagile-метод, що починається з інженеріїAgile-методологія кінця 1990-х, збудована навколо інженерних практик: розробка від тестів, парне програмування, безперервна інтеграція, рефакторинг і невеликі часті релізи. Від неї походить більшість того, що тепер називають технічною гнучкістю, і команда, яка переймає події Scrum без цих практик, зазвичай бачить, як її спринти сповільнюються.Усі терміни дала командам історії й задачі під ними. Книжки Майка Кона поширили «епік» як назву історії, завеликої для однієї ітерації, — за його власними словами, «магічного порогу» немає. Книжки Діна Леффінгвелла поставили епіки над фічами, а фічі — над історіями, і 2011 року це стало моделлю вимог SAFeSAFeScaled Agile Framework — фреймворк, що веде багато agile-команд як однуScaled Agile Framework — ролі, події та практики для координації десятків agile-команд, побудовані навколо Agile Release Train: пʼять-дванадцять команд, що планують разом раз на вісім-дванадцять тижнів. Це найбільш приписовий і найпоширеніший фреймворк масштабування — і саме тому його можна встановити, не змінивши того, хто ухвалює рішення.Докладніше в статті →Усі терміни. Трекери потім узяли кожен одну з цих форм, і форма, якою користується команда, зазвичай та, що прийшла з її інструментом.

Перейменування форми не змінює. З 2025 року інтерфейс Jira пише «work item» там, де раніше було «issue», а з жовтня 2025-го проєкт став «простором» (space). Ієрархія під цим — ті самі три рівні. Тож коли двоє сперечаються, чи є щось епіком, корисне питання — не визначення, а горизонт: скільки спринтів це триватиме і хто вирішує, чи продовжувати?

Для чого кожен рівень — і скільки їх потрібно

Більшість команд засвоює ієрархію як правило сортування: велике — в епіки, дрібне — в задачі. Цей опис правдивий і марний, бо не каже, де проводити межу, а «велике» — не властивість, яку можна перевірити.

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

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

Скільки рівнів тримати

• Одна команда

  Два рівні: історія і задача. Епік нічого не додає, коли один Product Owner тримає всю картину в голові.

• Кілька команд

  Три: епік, історія, задача. Епік — місце, де команди бачать, що працюють над однією ставкою.

• Програма

  Чотири-п’ять, з портфельним рівнем. Додавайте новий, лише коли реальна аудиторія ставить питання, на яке нижчий рівень не відповідає.

За замовчуванням має бути менше. Кожен рівень коштує часу на refinement, потребує чесного статусу й створює ще одне місце, де ту саму роботу описано двічі й вона розходиться. Тест для нового рівня — не «чи стане охайніше?», а «хто сьогодні ставить питання, на яке не має відповіді, і чи відповість на нього цей рівень?».

Два тести, куди належить елемент

• Тест на реліз

  Якщо випустити це окремо має сенс для користувача — це історія. Якщо сенс з’являється, лише коли вийде кілька частин, — це фіча або епік.

• Тест на аудиторію

  Якщо цього ніколи не прочитає ніхто поза командою — це задача. Задачі — робочі нотатки команди, а не рівень звітності.

Проженіть обидва тести на епіку вище. Рядок 1.2 сам по собі має сенс для клієнта, тож це історія. Фіча 2 має сенс, лише коли вийдуть 2.1 і 2.2: кошик, який можна зберегти, але не можна відкрити, марний, — тож це фіча. А п’ять задач під 1.2 ніколи не прочитає ніхто поза командою, тож їх не треба ні оцінювати, ні доводити до ладу на грумінгу, ні звітувати про них.

Як написати епік: гіпотеза, MVP і вихід

Епік — це ставка, а ставка, яку неможливо програти, ставкою не є. Щоб написати його як слід, потрібні три речі: у що ви вірите, сформульоване так, щоб це могло виявитися хибним; найменше, що можна збудувати, щоб це перевірити; і умова, за якої епік закінчується. Для першої SAFe дає шаблон — epic hypothesis statement, — і його варто запозичити, хоч би яким словником ви користувалися. Ось він, заповнений для епіка вище.

Найбільше роботи робить рядок випереджальних показників. Бізнес-результат на кшталт повернень проявляється за квартал і залежить від багатьох речей водночас. Випереджальний показник (leading indicatorleading indicatorранній, неточний сигналМетрика, що рухається рано й неточно передбачає пізніший результат, — скільки клієнтів користуються новою функцією в перші тижні як сигнал утримання наступного кварталу. Її протилежність, запізнілий показник на кшталт виручки, точна, але надходить надто пізно, щоб діяти.Докладніше в статті →Усі терміни) рухається за тижні й передбачає результат неточно: якщо майже ніхто не починає повторне замовлення з кнопки «Повторити», повернення через неї не зростуть. Без випереджальних показників рішення, чи продовжувати, можна ухвалити лише тоді, коли гроші вже витрачено.

MVP і рішення, заради якого він існує

MVP, minimum viable product, — найменша версія, що може довести або спростувати гіпотезу. SAFe вимагає його для кожного епіка. Епіки рухаються портфельною Kanban-дошкою: воронка, розгляд, аналіз, готові, реалізація MVP, реалізація понад нього, done. Робота над MVP зупиняється, коли витрачено відведені на нього гроші або гіпотезу доведено чи спростовано, — що станеться раніше. Лише доведена гіпотеза заробляє решту фіч.

В епіку вище MVP — це лише фіча 1, для кожного п’ятого клієнта, на чотири тижні. Якщо випереджальні показники зрушать, команда продовжує: фіча 2, потім розгортання на всіх. Якщо ні, епік зупиняють, і три фічі, яких ніхто не збудував, — це заощадження. Третій вихід — поворот (pivot): дані показують іншу ставку, яку варто зробити, — скажімо, клієнти повторюють замовлення з листа-підтвердження, а не з історії, — і ця ставка входить у воронку новим епіком зі своєю гіпотезою.

Умова закриття

Умова закриття — те, що запобігає вічному епіку. Без неї епік не має способу завершитися, тож під нього складають усе віддалено дотичне, і він переживає три реорганізації. З нею все, що лишилося на момент закриття, мусить виправдати себе як нова ставка, — а більшість залишків цього не може. Умова вище недарма каже «що б не показали дані»: епік, який закривають лише в разі успіху, лишається відкритим, доки хтось сподівається.

Під епіком: фічі, enabler-и, баги, спайки й задачі

Фіча — частина епіка, корисна тоді, коли виходить цілком. SAFe визначає її як функціональність, «розміром на поставку одним Agile Release TrainAgile Release Train5–12 команд, що планують і постачають разомУ SAFe — довгоживуча група з пʼяти-дванадцяти agile-команд, зазвичай 50–125 осіб, які разом планують на PI Planning, працюють до однакових меж ітерацій і щоітерації інтегрують свою роботу. Її варто проводити навколо шляху, яким продукт іде до клієнтів; потяг, проведений навколо наявних відділів, координує їх, нічого не змінюючи.Докладніше в статті →Усі терміни у межах PI», — інтервалу планування на вісім-дванадцять тижнів, — і дає кожній гіпотезу користі та критерії приймання. Поза SAFe корисний розмір — кілька тижнів. Рівень фіч виправдовує себе, коли кілька історій мають сенс лише разом, як 2.1–2.3; коли в кожній фічі по одній історії, рівень порожній і його варто прибрати.

Enabler-и: як назвати роботу, якої не просив жоден користувач

Enabler — елемент беклогу, який сам не дає видимої цінності, але уможливлює наступні елементи. SAFe визначає enabler-и як елементи, що «подовжують архітектурну злітну смугу рішення або покращують роботу потоку розробки», і вони можуть стояти на будь-якому рівні: enabler-епік, фіча чи історія. Їх називання не дає технічній роботі маскуватися під user storyuser storyпотреба з погляду користувачаКороткий опис того, що потрібно користувачеві й навіщо, зазвичай у формі «Як …, я хочу …, щоб …», — обіцянка розмови, а не специфікація. Слабкість тут та сама, що й сила: без критеріїв приймання, узгоджених у цій розмові, двоє людей збудують з однієї картки дві різні речі.Докладніше в статті →Усі терміни й дає їй легальний спосіб конкурувати за потужність.

Інструменти мають ту саму відмінність під іншими назвами. З травня 2015 року, коли сервіс ще називався Visual Studio Online, в Azure DevOps є поле Value Area — Business або Architectural, — додане разом із рівнем Epic для підтримки SAFe. У Jira зазвичай ставлять мітку чи окремий тип роботи. Важливе не поле, а домовленість, що йде з ним: фіксована частка потужності кожного спринту, відведена на enabler-и, щоб їх пріоритизували відкрито, а не витискали фічами. Типова відправна точка — п’ята частина.

Баги й спайки

Баг — не історія. Jira ставить його на рівень історій — поруч, а не під ними, — бо він конкурує за ту саму потужність спринту; Azure DevOps дає кожній команді вибрати, чи баги стоять з історіями, чи із задачами. Баг, записаний як історія, — «як клієнт, я хочу, щоб сума була правильною», — роздуває лічильник поставленої цінності. Спайк (spike) — обмежена в часі enabler-історія з одним питанням і письмовою відповіддю, як рядок 4.3. Без обмеження в часі й без питання він стає побічним проєктом.

Задачі: план команди, а не рівень звітності

Задачі — найстаріший рівень тут. В Extreme Programming програмісти на плануванні ітерації розкладали кожну історію на задачі, самі їх брали й самі оцінювали — по одному-три ідеальні дні. Scrum Guide зберігає суть і прибирає слово: робочі елементи на день або менше, розкладені «виключно на розсуд Developers». Обидва кажуть одне: рівень задач належить тим, хто робить роботу, і його завдання — зробити завтрашній план видимим для команди.

Чому підсумовані оцінки вводять в оману — і чим прогнозувати

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

Тож підсумкове число читається як прогноз, а поводиться як нижня межа. Поділіть його на velocity — і отримаєте дату, якої досягнуть, лише якщо за квартал ніхто нічого не дізнається. Графік вище ілюстративний, але його форма звичайна: лінія зробленого й лінія обсягу ростуть обидві, і розрив закривається значно пізніше, ніж обіцяла сума першого дня.

П’ять епізодів, що розставили слова по місцях

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

Читайте таблицю як історію розмірів. В Extreme Programming епіків не було взагалі: одиницею планування була історія, а задача — особистою справою програміста. Епік Кона — це історія, яку ще не розділили, кілька тижнів роботи, що чекають на рефайнмент. Епік Леффінгвелла — інший об’єкт, якому випало те саме ім’я: портфельне рішення, виміряне кварталами й грошима, з фічами та історіями під ним. Відтоді слово означало те, що означав інструмент перед вами.

Потім інструменти закріпили обидва значення. Microsoft 2015 року збудувала свій рівень Epic спеціально для SAFe, тож епік в Azure DevOps стоїть над фічею й має розмір портфельного елемента. Jira лишила епік вершиною трирівневої схеми, тож у більшості проєктів Jira він поглинає все — від двох тижнів до року. Команда, що переходить з одного інструмента на інший чи зливається з командою на іншому, успадковує плутанину без жодного ухваленого рішення.

Де вона вироджується

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

• Епіки без умови закриття перетворюються на постійні теки, що переживають три реорганізації.
• Епіки без гіпотези: MVP немає чого спростовувати, і кожен епік будують повністю.
• Рівень, доданий тому, що трекер його пропонує, а не тому, що хтось поставив питання.
• Дві групи вживають слово «епік» у різних розмірах і не помічають цього.
• Фічі, у кожній з яких одна історія, — рівень стає чистими накладними витратами.
• Історії, які насправді є задачами, — спринт заповнюється роботою, якої користувач не помітить.
• Технічна робота, замаскована під user story, замість того щоб бути названою enabler-ом і отримати потужність відкрито.
• Підзадачі за дисциплінами, що повертають передачі й показують прогрес, якого немає.
• Задачі, написані за місяці наперед, або оцінені й звітовані так, ніби це рівень для стейкхолдерів.
• Поінти, підсумовані вгору деревом і поділені на velocity, перетворюють нижню межу на обіцяну дату.

Чесна межа в тому, що ієрархія може зробити ставку видимою, а її розмір — зрозумілим; зробити ставку доброю вона не може. Бездоганно ведене дерево, де в кожного епіка є гіпотеза, MVP і умова закриття, однаково міститиме хибні ставки. Це не вада. Сенс структури в тому, що хибна ставка закінчується на своєму MVP і за ціною свого MVP, а не наприкінці року за ціною всього.

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

Коли це застосовувати

Пов’язані сторінки

• МенеджментUser StoriesUser story — це короткий опис потреби з погляду користувача, написаний, щоб почати розмову, а не замінити її. Шаблон — найменш важлива частина; справжня навичка — нарізати роботу так, щоб кожна історія давала користувачеві щось справді придатне, і ще до початку роботи домовитися, як усі зрозуміють, що її зроблено. Сторінка починається з шістнадцяти історій у тому вигляді, як їх справді пишуть команди, — що не так із кожною і як її переписати; далі — картка, розмова й підтвердження, критерії приймання та example mapping, дев’ять способів розділити історію, story mapping, INVEST, спайки й поінти, п’ять епізодів з історії формату і де все це вироджується.
• МенеджментWork Breakdown StructureWork Breakdown Structure (WBS) — це ієрархічний розклад усього, що проєкт має створити, — і, за визначенням, нічого поза цим. Це межа обсягу, намальована як дерево: якщо якоїсь роботи в ньому немає, її немає і в проєкті, а додати її — це зміна, а не правка. Сторінка починається з готового WBS для ІТ-проєкту — вісім гілок, тридцять один робочий пакет, з кодами й рівно 100% разом; далі — правила, що роблять дерево WBS, словник, де насправді живе обсяг, коди й контрольні рахунки, глибина розкладу, WBS поруч з agile-беклогом, три задокументовані кейси і де все це вироджується.
• МенеджментOKROKR (Objectives and Key Results) — це метод постановки цілей, що поєднує одну якісну ціль із двома-п’ятьма вимірюваними результатами, які доводять, що її досягнуто. Він прийшов з Intel 1970-х і дістався Google 1999 року, і працює лише тоді, коли key results вимірюють наслідки, а не задачі, коли committed і aspirational цілі оцінюють за різними правилами і коли оцінки не впливають на оплату. Сторінка починається з готових OKR однієї команди на квартал; далі — що насправді написали Ґроув, Дорр і Google, outcome і захисні метрики, як рахують оцінку, узгодження й тижневий цикл, OKR поруч із KPI та оплатою, чотири кейси і де все це вироджується.