Eric Willeke在思考：任务看板上的那些没有通过测试的用户故事，该怎么处理呢？应该把它回退到“开发”状态，还是保留“测试中”的状态？他提出了一些不同的方案：
● 一个方法是把开发和测试状态合并为“完成”状态，这样就不存在状态变化了。团队通过协作，分解出一系列小到能分配给单个开发人员/测试人员的子任务，但直到每个人都同意所有子任务都完成了，这个用户故事才算完成。
● 另外一种方法是把故事移到测试状态，需要的话再移回去，如此反复。如果这就是你日常工作中的真实情况，那么你应该以此建立模型。
● 还有一种方法是在某项上放置一个“缺陷”标志（或者缺陷卡片），但是在测试过程中当开发人员来帮忙修复缺陷的时候，标志还会一直放在那里，直到所有问题都被修复。如果这种情况更符合你的实际工作，你更应该以这种方式建立模型。
Thierry Henrio提出了不同的方案，他从精益制造行业借鉴过来了“红卡箱”（red bins）的概念：
我是这么做的：
● 每个状态栏都准备一个专用的红卡箱， 放在看板的底部靠上方
● 当某个状态栏的任务出现了问题，就把红卡箱移过去
● 我们有30分钟解决问题，消灭红卡箱
这套机制对于鼓励团队高效处理问题还是很有效的。但当问题出现在上游工序，那么30分钟就不够了，这种方法的效果也大打折扣。
专用的红卡箱相比红色标志，有更加强烈的可视化效果。
Ron Jeffries举了一个例子，解释了在任务板上，什么时候任务卡片应该流转回上游工序：
[...]如果任务又回到了原来的那位本应该搞定它的负责人的手上，那么把任务回退到前一步工序是一个不错的建立工作模型的方法。 不管你用哪种方法，Adam Sroka认为你的看板应该反映现实情况，而不是一些理想状态：
我们要为正在采用的步骤建立模型，而不是去给设想中的步骤建模，这一观点是很微妙的，却也非常重要。对我来说，这是今年夏天我参加了David主讲的研 讨会后，对看板最深刻的理解。可视化你在做的事情，随后，引入清晰的WIP限制，不断改进，等等。 对我而言，看板很适用。我也有XP的背景，我把流动可视化（visualizing flow）看成一种委婉的引入改变的方式。我过去常常在第一天就想做很多改变，现在我意识到，我可以通过帮助大家诚实地面对他们正在做的事情来轻松地做到 这一点。