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

Владелец продукта предоставляет данные финансовой модели, по которым определяются атрибуты и критерии на горизонте 3–6 месяцев. Например:

➠ Количество активных пользователей в день – от 10 тыс. до 100 тыс. человек.

➠ Объем хранимых данных на пользователя – от 3 до 6 мб.

➠ Раздача видео потока на одного пользователя – до 100 мб/мес.

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

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

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

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

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