ストーリーがテストに失敗したとき、かんばんボード上ではそれをどうすべきだろうか、Eric Willeke氏は考えた。「Development」に戻すべきだろうか、それとも「Testing」に残すべきだろうか？ 彼はいくつかの可能性を見つけた。
- 開発/QAの責任を「Done」に統合して動かさないことです。動かせるのは会話して合意されたときだけです。個々の開発者/テスターが一連の幅広いタスクを受け持つことで円滑になりますが、すべてのタスクが完了したと全員が合意するまではストーリーは完了しないことになります。
- テストするためにストーリーを動かすこと、前進させたり、後退させたりするなど、です。もしそれが現場で起こっていることであれば、あなたはそうモデル化すべきです。
- そのアイテムに「不具合」札（あるいはバグカード）を貼って、テストのままにしておくことです。開発者らはすべてを完了しようと、それらの解決を手伝いにやってきます。もしこれが起こっていることにぴったり合うのなら、あなたはそうモデル化すべきでしょう。
Thierry Henrio氏はリーン生産方式から借用した「赤いゴミ箱」を使った別のアプローチを提案した。
私はオプションのようなものを試してみました。
- 各ステージに専用の赤いゴミ箱を用意して、ボードの下に置きます。
- ステージのチェックリストに原因が挙げられると、それを赤いゴミ箱へ動かします。
- 赤いゴミ箱から取り出すのに30分あります。
これはチームの管理下にある原因に対して効果が見られました。しかし、原因が上流にあるときには、30分ポリシーは意味がなく、その効果は低下しました。
専用の赤い場所（ゴミ箱）は赤札よりも強烈な視覚効果があります。
Ron Jeffries氏はカードがタスクボードの流れに逆らわなくてはならないときの具体例を挙げた。
[...] もし、すでにその仕事に取り組んで、完了したものと思っていた人にその仕事が戻ってきたのなら、起こったことをモデル化するのには、流れに逆らうのがふさわしい方法のひとつです。
どんな手法を使おうとも、あなたのボードは理想状態ではなく現実を表現しなくてはならない。Adam Sroka氏はこうアドバイスした。
やりたいことではなく、やることをモデル化したいというアイデアは扱いが難しいが、極めて強力です。 私にとってこのことは、夏のDavid氏のコーチングワークショップから得た、かんばんに関する最大の発見でした。今やっていることを可視化するのです。それから、明確な仕掛り制限を導入して、改善すべきところを見つけるなどしましょう。これは私にとって非常にうまくいきました。私のバックグラウンドはXPにあるのですが、フローの可視化というのは、変化を取り込むための、やさしくて緩やかな方法だと考えています。かつては初日からすべてを変更したかったものですが、今では現在やっていることについてみんなが正直になれるよう助けることで、簡単に進歩できることを実感しています。