Якщо висловити свою точку зору коротко, то, як кажуть в Одесі: «Це дві великі різниці» :-).
«Критерії приймання» потрібні нам для перевірки кожної окремої Історії Користувача (фичи і т.п.) і підтвердження, що після реалізації система працює, як цього хотів замовник. Такі критерії будуть майже унікальні для кожного елемента беклога (Product Backlog Item) і повинні уточнюватися, перед тим як команда візьме той чи інший елемент в ітерацію (спринт).
Оскільки майже всі кроки «критеріїв готовності» повинні бути виконані для кожного елемента в беклоге, то найчастіше говорять про просте перевірочному списку. Досить докладно і з прикладами критеріїв про це написав Микола Алименко в своїй статті. Важливо пам'ятати, що ці критерії застосовуються до всіх елементів беклога, які були зроблені в спринті. Добре б запитати про ідеї ваших тестувальників і замовників, і тоді ви будете випускати «потенційно готовий продукт» максимально відповідний до вашої ситуації.
Якщо у вас команда, яка працює над довгостроковими випусками стабільної версії (т.зв. релізами), то, швидше за все, у вас будуть критерії ще більш високого рівня. Їх можна назвати «критерії готовності випуску» (Definition of Done for a Release). Ці критерії вплинуть на планування всього випуску, і про них треба пам'ятати постійно і не відкладати на останній момент.
Простий мозковий штурм дозволить вам зробити список з 3-10 елементів, якого буде більш ніж достатньо. Такий список стане в нагоді і для планування ітерації і, якщо є окремий список, то і для всього випуску. Адже необхідно запланувати рівно стільки функціональності, скільки ви встигнете зробити згідно з усіма пунктами перевірочного листа з «критеріями готовності». Будьте реалістами 🙂
Боремося з плутаниною в термінах: Критерії готовності VS Критерії приймання