Все заняты, а продукт не двигается

— Миш, вижу у тебя десять задач по бэку, какой статус?
— Пять сделал, приступаю к шестой
— Круто!

— Лен, а у тебя как дела со фронтом?
— Я почти все сделала, но вот тут заблокировалась
— Давай пока заблочены, вот эту задачку еще возьмем
— Окей

А какие фичи дошли до прода? Да хрен знает:)

——

Если на дейлике вы по очереди спрашиваете каждого человека о его задачах, то, скорее всего, оптимизируете занятость людей, а не движение продукта

Так появляется ложное ощущение, что цель разработчика — закрыть как можно больше своих задач. Хотя на самом деле цель продуктовой команды — доталкивать фичи до пользователя, а не поддерживать стопроцентную загрузку каждого участника

Бэкендер берёт следующую задачу, фронтендер — следующую. Количество одновременно начатых фич растёт, и по закону Литтла вместе с WIP растёт и Cycle Time

Итог весьма печальный — куча задач в работе, фичи переносятся между спринтами, на проде появляются только через месяц после того, как их взяли в работу

——

Вместо этого попробуйте ограничивать кол-во user story, которые одновременно в работе, и на дейликах смотреть именно на них

Например, в работе одновременно три user story. Проходимся по каждой из них и выясняем:
• что сейчас мешает довести фичу до пользака
• кто заблокирован
• кто может помочь
• какой следующий шаг

Таким образом меняется и смысл дейлика. Мы не пытаемся убедиться, что каждый чем-то занят. А вместо этого пытаемся понять, что нужно сделать команде, чтобы закончить начатое и с чистой совестью перейти к следующей user story