«Це важливо, але... не в цьому спринті»: як ви витягуєте свої задачі з вічного беклогу?
Ви підготували класну ідею або важливу технічну правку, приходите на планування, а вам кажуть класичне: «Це дуже важливо, але давай не в цьому спринті». Знайомо, правда? :)
І так тиждень за тижнем. Задача припадає пилом у беклозі, а пріоритет стабільно отримує щось зовсім інше.
Який аргумент у вашій команді працює найкраще, щоб задачу взяли в роботу прямо зараз? Що ви взагалі робите з ідеями, які вже місяцями висять у беклозі?
P.S. Якщо ви продакт чи скрам-мастер, то поділіться інсайдерським лайфхаком, як вам можна правильно пропхнути задачу, щоб ви самі захотіли взяти її в найближчий спринт?
5 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівЧас від часу роблю перегрумінг беклогу з якоюсь базовою приорітезацію. Типу ICE. І після цього зʼявляється розуміння — чому саме ця задача не потрапляє в спрінт.
P.S. Але для командної «менталочки» раз на квартал робимо cleaning спрінт, де не беремо продуктові задачі, а чистимо беклог від всяких мінорних багів, рефакторингу, міні фіч, покращень і т.п.
Аргумент простий: або приймаєте, або коли накопичиться втома від маразма, уйду в інше місце.
Працює не завжди, звісно. Але для персонального результату — годиться.
Нічого. Якщо задача валяється і не горить, тоді вона не потрібна продукту. Що потрібне, то не валяється. Просто видаліть все з беклогу, що лежить більше 2 месяців і забудьте.
На одному з проєктів у мене, який був започаткований десь в2003-му, беклог може тримати задачу і по 5 років. І потім воно таки іде у роботу.
Ну а якщо у вас такий короткий горизонт планування... або дійсне планування іде рівнем вище і не потрапляє на рівень робочих команд, або обстановка дуже специфічна, або ж ніхто не вміє планувати... і чомусь в більшости випадків вірним знаходиться саме останній варіант.
Повторювати мантру: «Не хочете видавати свою доньку заміж? Кохайтеся з нею самі!»