Например:
Установить сервер непрерывной интеграции
o Почему это надо сделать? Потому, что это сэкономит много времени разработчикам и снизит риск проблемы «большого взрыва» при интеграции в конце итерации.
Описать архитектуру системы
o Почему это надо сделать? Потому, что разработчики часто забывают общую архитектуру и поэтому пишут несогласованный код. Нужен документ, предоставляющий всем одинаковую общую картину.
Рефакторинг слоя доступа к данным
o Почему это надо сделать? Потому, что слой доступа к данным стал очень запутанным, и разработчики теряют много времени на то, чтобы разобраться и исправить возникающие дефекты. Рефакторинг сохранит время всей команды и повысит устойчивость системы.
Обновить Jira (систему учёта дефектов)
o Почему это надо сделать? Текущая версия очень нестабильная и медленная: обновление сохранит время всей команде.
Имеют ли смысл эти истории? Или это задачи не связанные ни с одной историей? Кто задаёт приоритеты? Нужно ли вовлекать сюда Product owner’а?
Мы попробовали различные варианты работы с техническими историями. Мы пробовали считать их самыми обычными user story. Это была неудачная идея: для Product owner’а приоритезировать их в product backlog’а было всё равно, что сравнить тёплое с мягким. По очевидным причинам технические истории получали самый низкий приоритет с объяснением: «Да, ребята, несомненно, ваш сервер непрерывной интеграции — очень важная штука, но давайте сперва реализуем кое-какие прибыльные функции? После этого вы можете прикрутить вашу техническую конфетку, окей?»
В некоторых случаях product owner действительно прав, но чаще все-таки нет. Мы пришли к выводу, что product owner не всегда компетентен, чтобы идти на компромисс. И вот что мы делаем:
1. Стараемся избегать технических историй. Ищем способ превратить техническую историю в нормальную историю с измеряемой ценностью для бизнеса. В таком случае у Product owner’а больше шансов найти разумный компромисс.
2. Если мы не можем превратить техническую историю в обычную, смотрим нельзя ли включить эту работу в уже существующую историю. Например, «рефакторинг доступа к данным» мог бы стать частью истории «редактировать пользователя», поскольку она подразумевает работу с данными.
3. Если оба подхода не прошли, отмечаем это как техническую историю и храним список таких историй отдельно. Пусть product owner видит список, но не редактирует. В переговорах с product owner'ом используем параметры «фокус-фактора» и «прогнозируемой производительности» и выделяем время в спринте для реализации технических историй.