Ігнорувати конфлікт, оскільки проєкт добігає кінця.

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

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

Ігнорувати конфлікт, оскільки команді вдалося досягти мети проєкту.

Предиктивний підхід (predictive approach), оскільки гнучкий використовується лише для проєктів з розробки програмного забезпечення.

Гнучкий підхід (agile approach), оскільки він задовольнить більшість стейкхолдерів.

Предиктивний підхід (predictive approach), оскільки це дасть більшу ясність проєкту.

Гнучкий підхід (agile approach), оскільки він дозволить отримати функціональні результати швидко.

Базове виявлення (Basic Identification)

SWOT-аналіз (SWOT Analysis)

Деталізоване виявлення (Detailed Identification)

Зовнішня перевірка (External Cross-check)

Внутрішня перевірка (Internal Cross-check)

Оцінити зусилля, необхідні для виправлення дефекту, а потім вирішити, що робити відповідно

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

Створити елемент для виправлення дефекту, додати його до беклогу продукту, а потім пріоритетизувати його

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

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

Застосувати техніку згладжування та натякнути, що в таких випадках можливі затримки.

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

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

Проведення опитування серед поточних користувачів проєкту.

Запрошення всіх зацікавлених сторін на семінар з вимог, щоб розробити користувацькі історії.

Надсилання анкети всім зацікавленим сторонам з метою визначення вимог проєкту.

Організації зустрічі з кожною зацікавленою стороною для визначення їхніх потреб.