Eric Willeke在思考：任務看板上的那些沒有通過測試的用戶故事，該怎么處理呢？應該把它回退到“開發”狀態，還是保留“測試中”的狀態？他提出了一些不同的方案：
● 一個方法是把開發和測試狀態合并為“完成”狀態，這樣就不存在狀態變化了。團隊通過協作，分解出一系列小到能分配給單個開發人員/測試人員的子任務，但直到每個人都同意所有子任務都完成了，這個用戶故事才算完成。
● 另外一種方法是把故事移到測試狀態，需要的話再移回去，如此反復。如果這就是你日常工作中的真實情況，那么你應該以此建立模型。
● 還有一種方法是在某項上放置一個“缺陷”標志（或者缺陷卡片），但是在測試過程中當開發人員來幫忙修復缺陷的時候，標志還會一直放在那里，直到所有問題都被修復。如果這種情況更符合你的實際工作，你更應該以這種方式建立模型。
Thierry Henrio提出了不同的方案，他從精益制造行業借鑒過來了“紅卡箱”（red bins）的概念：
我是這么做的：
● 每個狀態欄都準備一個專用的紅卡箱， 放在看板的底部靠上方
● 當某個狀態欄的任務出現了問題，就把紅卡箱移過去
● 我們有30分鐘解決問題，消滅紅卡箱
這套機制對于鼓勵團隊高效處理問題還是很有效的。但當問題出現在上游工序，那么30分鐘就不夠了，這種方法的效果也大打折扣。
專用的紅卡箱相比紅色標志，有更加強烈的可視化效果。
Ron Jeffries舉了一個例子，解釋了在任務板上，什么時候任務卡片應該流轉回上游工序：
[...]如果任務又回到了原來的那位本應該搞定它的負責人的手上，那么把任務回退到前一步工序是一個不錯的建立工作模型的方法。 不管你用哪種方法，Adam Sroka認為你的看板應該反映現實情況，而不是一些理想狀態：
我們要為正在采用的步驟建立模型，而不是去給設想中的步驟建模，這一觀點是很微妙的，卻也非常重要。對我來說，這是今年夏天我參加了David主講的研 討會后，對看板最深刻的理解。可視化你在做的事情，隨后，引入清晰的WIP限制，不斷改進，等等。 對我而言，看板很適用。我也有XP的背景，我把流動可視化（visualizing flow）看成一種委婉的引入改變的方式。我過去常常在第一天就想做很多改變，現在我意識到，我可以通過幫助大家誠實地面對他們正在做的事情來輕松地做到 這一點。