Это условия, при которых User Story можно брать в работу (в спринт). Если конкретная пользовательская история не соответствует этому критерию, то над ней нужно сначала провести некоторую работу.

Если брать в работу историю, которая еще не является достаточно понятной, или результат реализации которой не очевиден, или для которой не выявлены зависимости — вся работа может оказаться провальной. Поэтому команде важно иметь четкие DoR для элементов бэклога.

Используйте ретроспективу или другое свободное время, чтобы договориться с вашей командой о том, при каких условиях User Story можно брать в работу. После этого неукоснительно следуйте этому правилу, если только не измените ваше решение.

Через DoR члены Скрам–команды понимают, какие пользовательские истории завершены, а какие — нет. Этот критерий дает понимание, над чем нужно работать и что конкретно нужно сделать, чтобы пользовательскую историю можно было считать завершенной.

В этом тексте разберем подробнее, что такое DoR, как писать качественные DoR, разберем их на примере разных элементов фреймворка Scrum.

Definition of Ready — это рабочее соглашение между командой и Product Owner о том, что означает «готовность» User Story.

Это внутреннее условие для планирования пользовательской истории в спринте. Это критерий, дающий возможность Product Owner указать элемент в бэклоге продукта как готовый к работе в спринте — то есть что команда может его брать в работу (в противном случае, работу в задачу лучше не брать, ведь мы не знаем, что будет критерием выполненности).

Вспомним немного про зоны ответственности и права членов команды. Ответственность Product Owner заключается в том, чтобы каждая User Story имела Definition of Ready. Скрам–команда право отказаться от того, чтобы брать User Story в спринт. Команда делает прозрачными и понятными критерии, которым User Story должна соответствовать, прежде чем она будет принята в следующую итерацию.

Многие команды используют Definition of Done, чтобы проверить, готов ли продукт к реализации (поставке клиенту).

Но как насчет конкретных User Story, которые команда получает от Product Owner? Именно User Story команды могут проверять на качество с помощью Definition of Ready.

Хотя значение Definition of Done (DoD) давно понимают серьезные Agile команды, по нашему опыту, Definition of Ready (DoR) является одним из наименее используемых, и при этом не менее мощных инструментов, которые можно использовать.

Хотя DoR можно использовать для нескольких артефактов и действий (Product Backlog, Sprint Review и т. д.), для новых команд мы предпочитаем начинать с DoR для бэклога спринта. Это как бы вводит саму концепцию подготовки и планирования, что важно для оптимизации рабочих процессов.

• Определена User Story
• Выявлены возможные зависимости User Story
• Определены критерии эффективности, где это уместно
• Человек, который примет User Story, идентифицирован
• У команды есть понимание, что это будет значить для демо User Story

• Это измеряет «готовность» элемента бэклога
• Помогает команде определить, когда Product Owner или другой член команды перегружены
• Создает взаимную ответственность в команде
• Уменьшает давление на команду, снимая необходимость самостоятельно оценивать, когда User Story будут «готовы»

• В элементах Sprint Backlog расставлены приоритеты
• Sprint Backlog содержит все User Story и другие работы, которые выполняет команда
• Нет «скрытой» работы, имеется прозрачность процессов
• Все члены команды рассчитали свои возможности для спринта
• Полная занятость в проекте = X часов в день
• Все User Story имеют Definition of Ready

Начало работы с плохо понятой историей может создать много препятствий для Скрам–команды.

История без надлежащей информации может привести к работе не лучшего качества. Это в лучшем случае. В худшем случае работа принимает совершенно неправильное направление.

Совершенно очевидно, что User Story должна соответствовать ряду минимальных критериев, прежде чем она будет готова для включения в работу следующего спринта.

Этот набор минимальных критериев является Definition of Ready и, как и Definition of Done, должен быть согласован всей командой Scrum. Затем это общее определение позволяет команде отклонять истории, в которых нет четко определенных критериев приемлемости.

Практический совет: вы сэкономите много времени, если каждая User Story обретет свои Definition of Ready до планирования спринта.