В идеальном мире, в производственной системе, построенной по принципу вытягивания, задачи (ticket, work item) двигаются по потоку создания ценности слева направо, а информация справа налево. На доске канбан это будет соответствовать движению элементов (стикеров) только слева направо.
Но вот беда. Мир неидеален. Обнаруживаются дефекты и прочие причины, по которым часть работы в рамках решения задачи, приходится переделывать. Как это отображать на доске?
Варианты, с которыми доводилось сталкиваться, можно свести к следующим.

1. Задача остаётся на том месте, где выявлена необходимость в переделке (например, на этап тестирования). Необходимые ресурсы (например, разработчик) привлекаются для исправления ситуации, чтобы как можно скорее обеспечить дальнейшее движение задачи по потоку. Ведь эта задача — «блокер», поскольку блокирует поток (о чём мы делаем отметку, используя те правила визуализации, о которых нужно явно договориться). В этом варианте движения задачи «против потока» нет. Но то, насколько эффективной будет такая визуализация сигнала о необходимости привлечения ресурса, зависит от того, как у нас построенная практика работы с блокерами. Обычно анализ блокеров происходит в т.ч. на так называемых kanban meetings ежедневно (aka daily meetings). Всегда ли нам достаточно такой частоты, или хотелось бы передать сигнал быстрее? И, если быстрее, то насколько в нашей команде приемлемо прямое обращение к коллеге для привлечения внимания? Заметим, что это уже не столько про систему канбан как средство визуализации, сколько про команду, как группу эффективно взаимодействующих специалистов. Про культуру в том числе.
2. Задача возвращается на тот этап потока создания ценности, на котором требуется переделка. Обычно это сопровождается отметкой о возврате для последующего анализа и совершенствования нашей производственной системы. Здесь всё более-менее понятно, поскольку возврат происходит явно. Правда, «ломается» течение потока. В т.ч. усложняется работа с WIP-лимитами. Встречаются два варианта обработки: мы не учитываем возвраты при контроле лимитов (что несколько искажает смысл WIP-лимитов); или мы допускаем превышение лимитов, что усложняет их использование.
3. Задача остаётся на месте (как в варианте №1), создаётся дочерняя задача на переделку, которая отправляется туда, где переделка должна быть выполнена. Здесь будет комбинация плюсов и минусов предыдущих вариантов. У нас явно визуализирован блокер. Но зато (привет У. Оккаму) у нас появилась дополнительная сущность, а, следовательно, нам нужно контролировать связь между родительским и дочерним объектами. В системе автоматизации это не проблема. Но, например, для физической канбан-доски такой вариант, возможно, будет сложноват. Ну, и сказанное в п.2 про WIP-лимиты относится и к этому сценарию.
   Кстати, если передать дочернюю задачу вместе с родительской, то это фактически вариант №2. Хотя, например, Д. Андерсон и Т. Божева в описании модели зрелости канбан-систем (KMM) говорят о том, что именно такой сценарий характерен для системы более высоких уровней зрелости (4-й или 5-й).

Вроде бы других вариантов нет. Или есть?
Кажется, в большинстве случаев подойдёт второй вариант (его упомянутые авторы относят ко второму уровню зрелости [это хуже чем 4 и, тем более, 5 😊]).

А как поступаете вы?
Есть способы и/или аргументы помимо перечисленных?

ТРЕНАЖЁР

Kanban Flow Metrics: управление потоковым производством на основе данных

Тренажёр про метрики на реальных примерах