Принцип прост: если задача постоянно откладывается, значит, она недостаточно важна. Стоит принять этот факт и удалить её из списка. Нет смысла держать такую задачу в бэклоге или переносить её из спринта в спринт, так как это может подорвать доверие команды к актуальности бэклога. Они начнут сомневаться в приоритетах, если они постоянно меняются.
Просто удалите задачу. Не ставьте ей низкий приоритет, а введите специальный статус для закрытия, чтобы она не оставалась в списке. Не нужно ее постоянно держать в самом низу бэклога, лучше удалить её, если стало очевидным, что команда уже не обращает на неё внимания.
Если приоритеты актуальны, но в бэклоге всё равно остаётся "хвост" постоянно откладываемых задач, команда перестанет обращать внимание на бэклог. Они будут обращаться к вам с вопросом: "Что делать дальше?" Даже если в бэклоге всего пять задач, из которых две постоянно остаются внизу, и сверху появляются новые, команда всё равно будет спрашивать вас о следующих шагах, потому что бэклог не будет казаться им актуальным. В голове у членов команды будет мысль: "У нас в бэклоге есть задачи, которые мы не делаем, и я не знаю точно что нужно делать и нужно ли вообще".
Хотите управляемую команду - чистите бэклог. Команду надо приучать и показывать примером, что бэклог - это инструмент, что они могут работать с ним самостоятельно, без вашего вмешательства. Поддержание чистоты бэклога гораздо проще, чем микроменеджмент команды. Захламлённый бэклог отвлекает не только вас, но и команду, которая не будет смотреть дальше своей текущей задачи, потому что не будет понимать, что именно ей следует делать дальше.
Отвечу на возможный вопрос: "А вдруг задача понадобится, ведь задача важная?" Давайте откровенно, была бы она важна, она бы не откладывалась. Если в бэклоге куча ненужных задач, его всё равно никто не будет просматривать, и будут создавать дубликаты, а не искать уже созданные. Нет смысла хранить такие задачи. Сохраните их для себя. Введите статус "Removed" и возможность перевести задачу обратно в статус "New", если это будет необходимо. Это морально проще. Посмотрите статистику через несколько месяцев, и вы увидите, что вернули примерно нисколько.
Даже если что-то важное и всплывёт, оно будет рассмотрено в новом контексте, с новым видением. А это уже другая задача.
А что, если разработчик сообщил о чём-то важном, чтобы не забыть? Правило остаётся тем же: если задачу откладывают, значит, она переходит в статус "Removed". Я понимаю, очень хочется поддержать инициативность и не игнорировать мнения и идеи команды. Хотя отсутствие приоритета у задачи говорит об обратном — будьте честны по крайней мере сами с собой. Действительно ли задача важна? Пересмотрите её описание. Возможно, оно будет понятно только автору задачи, и если он покинет компанию, никто другой не возьмётся за её выполнение. Когда проблема станет актуальной, задачу можно будет сформулировать заново и решить.
Если у разработчика есть важная идея или задача, о которой он не хочет забыть, лучше поступить с этим иначе, чем просто добавлять в бэклог. Поощряйте разработчика хранить свои идеи в личных заметках и обсуждать их с вами на встречах 1 на 1. Этот подход намного эффективнее позволит команде чувствовать, что их вклад ценится, чем когда их предложения протухают на дне бэклога.
Если идея не имеет достаточной ценности, чтобы взять ее в работу без постоянного откладывания, то ей место не в бэклоге. Он не должен использоваться как свалка для каждой мысли. Бэклог - это стратегический инструмент, предназначенный для приоритизации и организации задач, готовых к выполнению и имеющих ясную важность для текущих целей проекта.
Поддерживайте бэклог в чистоте, и ваши команды будут вам благодарны.
Здравствуйте! Меня зовут Леонид Нетребский. Я руковожу разработкой и проектами с 2013 года и занимаюсь тим-лидерством с 2009 года. У меня есть опыт управления командами разработчиков до нескольких десятков человек. Есть опыт управления разработкой в компаниях с полной анархией, пропитанной пилением бюджетов, до адептов метрик производительности. Я тот руководитель, кто выстраивает процесс комплексно, включая CI/CD, автоматизацию тестирования, архитектуру, SRE. При необходимости я также могу написать код, чтобы продемонстрировать пример или что-то попробовать.
Когда-то я хотел писать в блог, чтобы сказать что-нибудь. Теперь мне есть что сказать и очень рад делиться своим опытом и наблюдениями в области управления разработкой ПО.
