Це український переклад статті Євгенія Лабунського, яка була написана ще в 2018 році на прохання допомогти з метриками від його дружини, Дар'ї Алімової. Стаття є результатом їхнього багатогодинного брейншторму, який доповнений особистими роздумами Євгенія щодо тієї чи іншої метрики. Російську версію матеріалу можна прочитати тут.

Сумнівні метрики

Середня кількість дефектів на User Story. Тренд дефектів у динаміці (over time)

Що показує: фактично відображає тренд зменшення або збільшення якості на одну історію користувача. Цікаво розглядати в динаміці щонайменше за 2 місяці.

Вимагає адекватного ведення Backlog'а задач, де нарізка для команди йде у вигляді end-to-end функціональності, а також фактично заведення кожного дефекту (з прив'язкою його до певної задачі).

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

Різновид: кількість дефектів на Story Point, реліз, Epic тощо.
Загальний вердикт - краще не використовувати, або робити це так, щоб ніхто не знав.

Burn Down Chart

Що показує: тренд спалювання часу/обсягу задач у відношенні до ідеального тренду.

Як це має бути (очікування)

Класичний Burn down показує, наскільки команда добре… трекає час. Ось приклад неефективної роботи у команді, де Burn down показуватиме ідеальний тренд:
Є спринт, у якому є 5 завдань. Команда починає виконувати 5 завдань одночасно, всі зайняті та відмінно списують час. І ось, кінець спринту і ... дуже багато дефектів щодо того, що щось не встигли або щось не склеїлося. Але 90% спринту ваш тренд за часом був ідеальним, ось як цей:

Але щось пішло не так, і ви дізналися про це пізно. Все тому, що:

Burn Down Chart не показує те, ЯК ви робите роботу.

Читаючи цей рядок багато хто скаже, що тоді варто будувати чарт у Story Points. Ваша думка буде слушною лише за наступних умов:
1. Задачі оцінені дрібно
2. Ви виконуєте задачу за задачею, а не починаєте все одразу (це справедливо й у випадку з годинником)

Але все ж таки, доки історія не буде завершена, графік буде строго горизонтальний і, власне, нічого не показує. Як цей. Станом на 25-е число ви все ще не знаєте, чи зможете щось закрити і, чи вистачить вам часу.

Різновиди: Epic Burn Down, Release Burn Down. Уникайте всього, що «бернить даун».

Висновок: якщо хочете дивитися, як люди трекають час  - burn down ваш вибір. Якщо хочете розуміти, як покращувати роботу команди, використовуйте фізичні дошки та інші візуалізації руху РОБОТИ.

Committed vs. Delivered

Мета: вимірювати обіцянки команди та факт. Дуже поширена серед менеджерів різних рівнів.

Що показує: показує, наскільки добре ваша команда вміє вас дурити. Жарт. Показує спринти, в яких вашу команду спитають "ДОКИ?". Це не жарт.
Дуже токсична метрика. Зазвичай призводить до того, що команда починає робити наступне (щось з цього або все одразу):
- Завищувати оцінки
- Занижувати оцінку продуктивності (velocity)
- Нехтувати якістю заради завершення завдань

Така проблема, що в ІТ все дуже відносно. Код і написання коду - дуже творчий процес, який складно оцінити за своєю суттю.

Використання цієї метрики веде до тотальної демотивації команди, появі фраз "ну ви ж обіцяли!" або "ви завжди щось обіцяєте, але не робите".

Ніколи не використовуйте цю метрику.