Це український переклад статті Євгенія Лабунського, яка була написана ще в 2019 році. Її можна прочитати тут.

Burn-up Chart

Що це: показує, як ви з’їдаєте скоуп (обсяг) до дати або, навпаки, до якої дати буде зроблено цей обсяг скоупа.

Зображення з https://spin.atomicobject.com/2016/03/31/burn-up-charts/

Що ми тут маємо:
- Вісь Х — спринти, вісь Y —обсяг. Обсяг міряємо в Story Points або штуках (кількості) завдань.
- Зелений тренд — фактично поспринтова Velocity команди.
- Синій тренд  —  поточний обсяг завдань та його зміна від спринту до спринту (тобто обсяг беклогу).
= Зелений тренд — як команда спринт за спринтом «споживає» беклог.

Що нам це дає? Ми можемо прогнозувати. Наприклад, коли буде зроблено весь цей обсяг завдань?

Чи що буде зроблено до Різдва?

У Agile світі ми віддаємо перевагу прогнозу «до дати», тому що обсяг завдань, як правило, зростає. Тому при плануванні «від обсягу» ви можете потрапити в ситуацію, коли «давайте ще доробимо це завдання, тому що без нього ніяк».

End-to-end time to market (Lead time)

Що це: ця метрика показує, скільки часу проходить із моменту появи ідеї до моменту її фактичної реалізації та появи на стороні користувача.

Часто в розробці команди вимірюють те, наскільки швидко вони роблять саму Feature, тобто скільки часу проходить із моменту початку роботи до продакшина.

Проте набагато цікавіше те, скільки часу минуло загалом від ідеї до реалізації. Й ось чому:

Ви дізнаєтесь, скільки реально часу бізнес у середньому чекає одну фічу

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

Ефективність потоку (Flow Efficiency)

Будь-яка робота — це сукупність активних стадій, коли робота виконується, та стадій очікування, коли завдання очікує на виконання або наступній стадії.

Зображення з https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Наприклад, візьмемо спрощений процес розробки з погляду завдання:

Опрацювання деталей — Розробка — Тестування — Випуск

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

Якщо ви вважаєте час, який витрачається на «роботу» над завданням, то є активний час, а так само час, який завдання проводить в очікуванні. І ви можете порахувати Ефективність потоку — співвідношення очікування та активної роботи.

Якщо працювали над завданням 1 день (затрекали час), а фактично між активною роботою вона провела 2 дні (час очікування), ефективність такого потоку = 1/(1+2) * 100 = 30 %

Це означає, що 70 % часу робота не ведеться, тобто завдання «простоює».

Кількість елементів у беклозі

Що міряє: міряє кількість елементів у беклозі :)

Навіщо міряти? Щоби розуміти, скільки сміття на вашому «складі». З погляду Lean беклог — це склад. Зайві складські запаси — один із видів втрат.

Як за будь-яким складом за беклогом потрібно доглядати, переглядати, оцінювати, чистити та інвентаризувати.

Чим більше ваш беклог — тим менше ви розумієте, що в ньому зберігається й тим менша його фактична актуальність

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

Немає цифри, яка б ідентифікувала межу:) Це все дуже специфічно для команди/продукту/компанії. Просто пам’ятайте, що навряд чи варто зберігати завдання, яким кілька років, щоби «не забути» :)

Термін життя елемента беклогу

Попередня метрика тісно пов’язана з цією метрикою: чим старіше завдання в беклозі, тим менше сенсу вони мають.

Старість беклогу зазвичай говорить про такі проблеми:

1. Накопичення: завдання створюються, щоби «не забути».
2. Відсутність «власника» беклога. Тобто ставлення команди до нього, як до орендованої машини: ви не миєте її. Усім байдуже, що там у них робиться. Тобто з беклогом не працюють, не «грумлять».
3. Власник продукту не вміє говорити НІ, тому додає все, що його просять.

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

Еволюція Definition of Done

Як виміряти роботу Scrum Master? Дуже просто. Потрібно зрозуміти те, наскільки росте Definition of Done його команди. Цим самим можна виміряти «дорослішання команди».

Саме збільшення критеріїв готовності чудово відображає, наскільки зростає технічна усвідомленість команди, наскільки швидко ви можете робити зміни, наскільки швидкий зворотний зв’язок і наскільки ви близькі до клієнта.

Саме збільшення критеріїв готовності чудово відображає, наскільки зростає технічна усвідомленість команди, наскільки швидко ви можете робити зміни, наскільки швидкий зворотний зв’язок і наскільки близькі до клієнта.

Якщо команда рік сидить із критеріями «код написаний та протестований», то за минулі 12 місяців ви не почали більше Agile у вашій компанії. Ви лишилися на минулому рівні. Не розвинулися технічно, управлінсько та продуктово.