Чеклист acceptance criteria, который остаётся на рабочем элементе

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 получает свой список — та же идея, другие примеры.

Этот список принадлежит только этой story. В Checklist for Jira вы добавляете такие пункты прямо на рабочий элемент, отмечаете их, когда поведение появляется, и сохраняете короткий стартовый шаблон, когда форма stories команды повторяется — с новыми примерами каждый раз.

Сохраните каркас, правьте под story

1. Checklist for Jira добавляет панель Checklist в вид задачи. Добавьте туда acceptance criteria для своего сценария — возьмите пример выше как паттерн и заполните строки под вашу работу.
2. Если нужен переиспользуемый каркас, сохраните заголовки (охват, happy path, ошибки, готовность к демо) как проектный или глобальный шаблон, затем переписывайте каждую строку, когда стартует следующая story.
3. Можно настроить автоматизацию шаблона, чтобы каркас добавлялся при создании Story или при переходе в In Progress — или применять вручную через Add → Add from template, когда нужно.
4. Если команда хочет жёсткие гейты в процессе, добавьте валидатор завершения на переход workflow.
5. Сбрасывайте или обновляйте пункты, когда сдвигается охват; в конце сочетайте с Definition of Done и чеклист QA-тестирования, когда тестировщики ведут проход — см. руководство по автоматизации.

Сочетайте с остальным набором доставки

Держите Definition of Done на той же задаче для планки отгрузки. Вешайте чеклист QA-тестирования, когда нужен структурированный тестовый проход. Используйте Definition of Ready на refinement, если качество intake помогает команде. Полный набор — в хаб шаблонов.

Частые вопросы