Scrum обмежує роботу переліком елементів беклогу, а Kanban — часом виконання заявки

Scrum обмежує роботу часом ітерації, а Kanban — кількістю елементів на кожному кроці процесу

Scrum обмежує роботу кількістю учасників команди, а Kanban — кількістю колонок на дошці

У Scrum обсяг робіт не змінюється до кінця ітерації, а в Kanban пріоритет можна змінити будь-коли

В інкрементній усі вимоги відомі на початку, а в еволюційній уточнюються від версії до версії

В інкрементній порядок випусків планують наперед, а в еволюційній його задає реакція користувачів

В інкрементній зміни вносять у наступну версію, а в еволюційній — у вже випущену версію

В інкрементній кожна версія працездатна, а в еволюційній працездатною є лише остання

Перевищення запланованого бюджету проєкту через затримку здачі окремих його функцій

Різницю між станом коду, якого вимагає прийнята технологія, і тим, до якого звели справу

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

Перелік відомих дефектів, які команда вирішила не виправляти до наступного випуску

Викликач мусить знати внутрішні гілки викликаного, а кожен новий режим змінює обидва модулі

Передана за посиланням структура може бути непомітно змінена тим модулем, який її прийняв

Модулі починають читати й записувати ту саму глобальну змінну, і джерело зміни невідоме

Через прапорець режиму в сигнатурі важче зрозуміти, що саме робить викликаний модуль

Коли програму пише одна людина, а обсяг коду залишається невеликим

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

Коли предметна область складається з довговічних сутностей із власними правилами й станами

Коли частини системи потрібно розгортати й оновлювати незалежно одна від одної

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

Обладнання поводилося не так, як припускали автори програмної частини під час розробки

Дефект жив на межі між компонентами системи, а не всередині окремо взятого компонента

У коді залишилася помилка, якої не виявили модульні тести, написані самими розробниками

Рідкі великі випуски вимагають ручного розгортання, а часті виконує конвеєр автоматично

Велика кількість змін в одному випуску підвищує навантаження на промислове середовище

Виправлення доходить до користувачів у день появи помилки, а не через два тижні

У малій зміні причина інциденту очевидна, а повернення до попереднього стану дешеве

Від тривалої роботи в коді накопичуються дрібні дефекти, які доводиться періодично усувати

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

Збережені дані поступово псуються, і разом із ними доводиться виправляти програмний код

Виходять нові версії операційної системи й платформи, під які продукт треба оновлювати

Компонент має оголошений інтерфейс, через який до нього звертається решта системи

Компонент постачають як готовий двійковий артефакт з описаним контрактом і власною версією

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

Компонент поєднує дані предметної області разом з операціями над ними

Модулі виділяють за технологіями: окремо база даних, окремо обчислення, окремо інтерфейс

Кожен модуль має приховувати одне проєктне рішення, яке з великою ймовірністю зміниться

Кожен модуль має реалізовувати визначену функцію і взаємодіяти з іншими через інтерфейс

Модулі виділяють за етапами обробки: окремо читання, окремо перевірка, окремо запис