Определение готовности в Scrum

У конечных пользователей иногда возникают идеи или концепции для новых функций. Концепция представлена ​​в виде одного или нескольких функциональных элементов и добавлена ​​владельцем продукта в список невыполненных работ. Команда будет работать вместе, чтобы выяснить, как воплотить эту концепцию в один или несколько эпиков, а затем доработать ее до небольших и более понятных пользовательских историй, которые будут включены в реализацию следующего спринта как реальная функция продукта.

Однако подготовка пользовательских историй до начала спринта может оказать прямое и существенное влияние на продуктивность команды. Наличие определения «готовность» означает, что история должна быть немедленно готова к реализации. Команда должна быть в состоянии определить, что нужно сделать, и объем работы, необходимый для завершения пользовательской истории.

Команда перетащит истории из верхней части бэклога продукта в бэклог спринта. Эти истории должны быть «готовы». Некоторым компаниям на самом деле нужен подробный список, чтобы определить, «готова» ли история, а не просто «почти».

Как создать определение готовности?

Владелец продукта может работать вместе с командой над определением  артефакта ,  называемого «определением готовности», чтобы гарантировать, что элементы в верхней части списка задач готовы к перемещению в спринт, чтобы команда разработчиков могла уверенно зафиксировать и завершить их. конец спринта.

Почему определение готовности?

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

• Измерьте «готовое» состояние элемента невыполненной работы
• Убедитесь, что элементы бэклога продукта продуманы «достаточно»
• Помогите команде определить, когда владелец продукта или другой член команды становится перегруженным
• Держите команду подотчетной друг другу
• Уменьшите нагрузку на команду, чтобы она выполняла оценки до того, как истории будут «готовы».
• Уменьшить «изменение требований» в процессе разработки

Пример — определение готовности к спринту

Разные команды будут иметь разное Dentition of Ready, а некоторым требуется меньше. т. е. некоторые команды просто описывают ценность для пользователя, расставляют приоритеты и пишут, как продемонстрировать. Другие оценки и общение находятся на  совещании по планированию спринта  и т. Д. Вот примеры элементов, которые следует учитывать при разработке DOR для вашей команды:

• Бэклог  спринта  имеет приоритет
• Spring Backlog содержит все дефекты, пользовательские истории и другую работу, над которой работает команда.
• Нет скрытой работы
• Все члены команды рассчитали свои возможности для спринта.
• Полный рабочий день на проекте = X часов в день
• Все пользовательские истории соответствуют определению готовности

Пример — определение Ready для пользовательской истории

В этом разделе показан образец определения готовности для пользовательской истории и образец определения готовности для спринта. Вы можете принять некоторые из них в качестве базовых или отправных точек:

• Четко указана ценность Story для пользователя.
• Критерии  приемлемости  для Story были четко описаны.
• Определены зависимости User Story
• Пользовательская история оценивается командой доставки
• Scrum  Team принимает артефакты User Experience
• Определены критерии эффективности, где это уместно
• Определяется лицо, которое примет User Story.
• Команда знает, как продемонстрировать историю.

Резюме

Термин «определение готовности» не описывается в руководстве по схватке. Это то же самое, что пользовательская история и встроенные в нее критерии приемлемости. Возможно, вы думаете, что определение готовности является неотъемлемой частью деятельности по уточнению невыполненной работы по продукту, а не использованием определения готовности в качестве контрольного списка последовательности и этапа. Уточнение невыполненной работы — это непрерывный процесс, поэтому он не ограничивается событием, а рассматривается как действие.