И о полезном.

Наша наивная идея (и эти грешат многие материалы и тренинги по разработке продукта) состоит в том, что бэклог - это набор user stories для новых фич.

Но жестокая действительность разбивает наши мечты, приходя в виде тикетов от саппорта, технического долга вследствие срезания углов («надо успеть к релизу»), и ультиматумов (обоснованных!) от команды о необходимости выделять время для проработки архитектуры («ребята, ну сколько можно говорить и рисовать, давайте писать код!»).

Один из подходов, о которых я еще не писал - это матрица для форматирования бэклога на основе двух осей:
Прошлое - Будущее
Бизнес - Разработка

Основная идея состоит в том, чтоб зарезервировать % времени под каждый блок работы, и перестать мучаться в сомнениях при планировании каждого спринта.

В зависимости от специфики и зрелости вашего продукта, это соотношение будет разным. Очевидно, максимум внимания хочется уделять новым фичам. Я бы сказал, в моем случае (В2В энтерпрайз софт, с которым работают крупные глобальных корпорации, и есть определенные платформенные зависимости, 20+ скрам-команд, которые координируют свои усилия) это выглядит так:

Новый функционал - 60%
Техдолг - 10%
Проработка архитектуры - 10%
Саппорт - 20%
(один из разработчиков в каждой команде резервируется под сложные кейсы и срочную помощь энтерпрайз-кастомерам, изменения вносятся сразу также в коробку и выходят в следующем релизе для всех)

В итоге, приходится признать, что если ваш продукт довольно зрел, то на собственно развитие вы будете тратить не более 60-70% - и это еще очень хорошие цифры 😉

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