Acceptance criteria vs Definition of Done vs ready
Definition of Done однакова на кожній story: тести, рев’ю, документація. Acceptance criteria змінюються разом із роботою — «власник акаунта може експортувати CSV менш ніж за п’ять секунд». Definition of Ready запитує, чи є ці приклади до старту. чекліст QA-тестування — як ви їх доводите. Усі три як чеклісти на робочому елементі підвищують ясність і зрізають двозначність — статус і наступні кроки видно без полювання за скарбами.
Приклад: API, який віддає список завдань Jira
Acceptance criteria зазвичай відрізняються від story до story — кожен список описує, що має дати цей робочий елемент. Уявіть елемент беклогу, який команда реально може взяти: зібрати GET-ендпоінт, який повертає пагінований список завдань Jira за проєктом. Продукту потрібні зрозумілі поля й права. Інженерії — домовленість щодо пагінації та форм помилок. QA — що можна швидко показати curl-ом на демо.
Чекліст нижче — те, що така story могла б нести на робочому елементі: не шаблон для будь-якого API, а патерн: хто може викликати, як виглядає успіх, як виглядає помилка і як показати, що це працює.
Найкращий тест кожного рядка: чи можна це демо без здогадок? Наступна story отримує свій список — та сама ідея, інші приклади.
Acceptance criteria — API списку завдань Jira
- Охоплення
- Автентифікований користувач із правом browse у проєкті може викликати GET /issues
- Відповідь — JSON; UI-робота лишається поза цією story
- Повертаються лише завдання в Open, In Progress і Done, якщо робочий елемент не каже інше
- Happy path
- GET /issues?project=ENG повертає 200 із ключем, summary і статусом кожного рядка
- Query-параметри page і pageSize працюють; значення за замовчуванням задокументовано на робочому елементі
- Відповідь містить загальну кількість, щоб клієнт міг пагінувати
- Помилки
- Невідомий проєкт повертає 404; користувач без browse отримує 403
- Проєкт без завдань повертає 200 з порожнім списком
- Некоректні page або pageSize повертають 400 із зрозумілим тілом помилки
- Демо
- Додано приклад curl — кожен рядок вище демонструється з нього
- Відкриті питання закрито або відкладено до старту розробки
Цей список належить лише цій story. У Checklist for Jira ви додаєте такі пункти прямо на робочий елемент, позначаєте їх, коли з’являється поведінка, і зберігаєте короткий стартовий шаблон, коли форма stories команди повторюється — з новими прикладами щоразу.
Поставте це на робочий елемент із Checklist for Jira
Шаблони, автоматизація, обмеження в процесі та агент Rovo — безкоштовно для команд до 10 користувачів.
Збережіть каркас, правите під story
- Checklist for Jira додає панель Checklist у вигляді завдання. Додайте туди acceptance criteria для свого сценарію — візьміть приклад вище як патерн і заповніть рядки під вашу роботу.
- Якщо потрібен каркас для повторного використання, збережіть заголовки (охоплення, happy path, помилки, готовність до демо) як проєктний або глобальний шаблон, потім переписуйте кожен рядок, коли стартує наступна story.
- Можна налаштувати автоматизацію шаблону, щоб каркас додавався під час створення Story або під час переходу в In Progress — або застосовувати вручну через Add → Add from template, коли потрібно.
- Якщо команда хоче жорсткі гейти в процесі, додайте валідатор завершення на перехід workflow.
- Скидайте або оновлюйте пункти, коли зсувається охоплення; наприкінці поєднуйте з Definition of Done і чекліст QA-тестування, коли тестувальники ведуть прохід — див. посібник з автоматизації.
Поєднуйте з рештою набору доставки
Тримайте Definition of Done на тому самому завданні для планки відвантаження. Вішайте чекліст QA-тестування, коли потрібен структурований тестовий прохід. Використовуйте Definition of Ready на refinement, якщо якість intake допомагає команді. Повний набір — у хаб шаблонів.
Часті запитання
Хто володіє acceptance criteria?
Зазвичай продукт накидає, інженерія й QA загострюють. Чекліст на завданні робить цей обмін видимим, а не ховає його в коментарях.
Чому інженерія й QA люблять acceptance criteria на завданні?
Бо чекліст — місце, де вони отримують і розуміють вимоги: конкретні приклади, за якими можна збирати й тестувати, видимі поруч із роботою, а не сховані в описі чи слайдах.
Чи можуть acceptance criteria змінюватися після старту розробки?
Часто так. Позначайте або оновлюйте пункти на робочому елементі, коли зсувається охоплення, і прив’язуйте обговорення туди, щоб список лишався джерелом правди.
Як зрозуміти, що критерій достатньо добрий?
Запитайте, як ви це будете демо. Якщо ніхто не може показати поведінку в короткому walkthrough, рядку ще бракує деталей.
Поставте це на робочий елемент із Checklist for Jira
Шаблони, автоматизація, обмеження в процесі та агент Rovo — безкоштовно для команд до 10 користувачів.