Этот шаг предполагает следующую работу, основанную на плане измерения проекта:

• Сбор данных простых показателей
• Вычисление и проверка показателей
• Включение показателей в отчет об оценке состояния

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

Для итераций, которые длятся недели или месяцы, сбор показателей и составление отчетов будет непрерывным процессом, а промежуточные результаты будут периодически фиксироваться в Рабочий продукт: Оценка состояния.

Перед окончанием каждой итерации ядро коллектива должно собираться вместе для ее оценки, сфокусировавшись при это на следующем:

• Достигнуты ли цели итерации?
  • Были ли риски уменьшены или устранены?
  • Достигнуты ли запланированные функциональность и качество выпуска? Достигнуты ли запланированные производительность и мощность?
• Требуется ли внести изменения в проект и план будущих итераций?
• Были ли аннулированы какие-либо полученные данные, зафиксированные в Рабочий продукт: Оценка организации разработки, из-за изменений в процессе итерации (в результате изменений других рабочих продуктов проекта, таких как Процесс разработки)?
• Возникли ли трудности с  Процесс разработки  проекта в ходе итерации?
• Для какой доли текущего выпуска была создана контрольная версия? Переделана?
• Определены ли новые риски?
• Произошли ли внешние изменения (изменения на рынке, в сообществе пользователей или в требованиях)?

Оцените результаты итерации с помощью критериев оценки, установленных для плана итерации: функциональность, производительность, мощность, показатели качества. Используйте показатели, полученные в процессе тестирования, и шаг Сбор показателей как основу для оценки. Качественные показатели подходят для начального этапа и, возможно, для ранних итераций, в то время как на этапах уточнения, построения и внедрения должны использоваться специфические измерения тестов для оценки качества, производительности, мощности и т.д. Решите другие нерешенные проблемы, зафиксированные в оценках состояния, которые были выполнены в ходе итерации, а также те, которые указаны в Списке проблем Администратора проекта.

Если все риски были уменьшены до приемлемого уровня, вся функциональность была реализована и все цели качества были достигнуты, то продукт выполнен. Хорошее планирование и выполнение плана являются ключевыми условиями достижения этого к концу этапа Внедрения.

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

Если принять во внимание состояние внешней среды, остается ли верным план проекта (включая вехи)? Существуют ли изменения рисков, требующие пересмотра планов итераций? Создается ли правильный продукт и остается ли верным видение? Остается ли коллектив на своем пути к реализации продукта? Не требуется ли внести изменения в процесс из-за изменения внешних обстоятельств?

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

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

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

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

На основании результатов оценки запросы на изменения для Видения, Списка рисков, Плана разработки программного обеспечения, Плана итерации, project's Процесса разработки и Требований к программному обеспечению.