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

Рівні — це про горизонти

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

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

Для чого кожен рівень

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

Те саме слово, три різні розміри

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

Одну відмінність із SAFe варто запозичити незалежно від вашого словника: business проти enabler. Бізнес-елемент дає цінність, яку користувач бачить. Enabler будує те, що уможливлює майбутні бізнес-елементи: інфраструктуру, архітектурну зміну, роботу з відповідності чи дослідження. Явне називання enabler-ів не дає технічній роботі маскуватися під user story й дає їй легальний спосіб конкурувати за потужність, а не ховатися в оцінках.

Скільки рівнів вам потрібно?

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

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

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

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

• Програма

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

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

Де насправді проходять межі

Два практичні тести знімають більшість суперечок про те, до якого рівня щось належить.

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

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

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

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

Корисний наслідок тесту на аудиторію: задачі не потребують оцінювання, грумінгу чи вилощеного опису. Час, витрачений на «презентабельність» рівня задач, забрано в рівнів, які хтось справді читає.

Епіку потрібні гіпотеза й вихід

Епік — це ставка, а ставка, яку неможливо програти, ставкою не є. Написати його як слід — це два речення: у що ви вірите, сформульоване так, щоб воно могло виявитися хибним, і умова, за якої епік закривається. «Ми віримо, що можливість зберегти кошик підніме повторні візити на другому тижні з 18% до 25%; ми закриємо цей епік, коли збережені кошики працюватимуть для всіх користувачів і ми матимемо чотири тижні даних — якими б ті дані не були».

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

Чому підсумовані оцінки вводять в оману

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

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

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

Як це виявляється в реальній поставці

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

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

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

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

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

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

• МенеджментUser StoriesUser story — це короткий опис потреби з погляду користувача, написаний, щоб почати розмову, а не замінити її. Шаблон — найменш важлива частина; справжня навичка полягає в нарізанні роботи так, щоб кожна історія давала користувачеві щось справді придатне до використання. На цій сторінці — три C, критерії приймання, шість способів розділити історію, story mapping, spike та призначення story points.
• МенеджментWork Breakdown StructureWork Breakdown Structure (WBS) — це ієрархічний розклад усього, що проєкт має створити, — і, за визначенням, нічого поза цим. WBS — це межа обсягу, намальована як дерево: якщо якоїсь роботи в ньому немає, її немає і в проєкті. На цій сторінці — правило 100%, словник WBS, контрольні рахунки, схема нумерації та питання глибини розкладу.
• МенеджментOKROKR (Objectives and Key Results) — це одна якісна ціль у парі з кількома вимірюваними результатами, які доводять, що її досягнуто. OKR — інструмент постановки цілей і узгодження; щойно вони стають списком задач чи оцінкою продуктивності, вони перестають працювати — і зазвичай саме їх у цьому й звинувачують. На цій сторінці — outcomes проти outputs, committed проти aspirational, каденція, оцінювання та відмінність від KPI.