あきぴーさんの記事を読んで、そもそも scrum が組めていればそもそも起こらないんじゃないの？と思ったのでつらつら書いてみる（あきぴーさんも書いているけど）
チケット駆動開発のアンチパターン: プログラマの思索
1-1,乱発されたチケット
スプリントプランニングでタスク分割をメンバー全員で行う。
よって、チケットはメンバー全員で合意の上で作成されるので、乱発されることはない。
テスト時の不具合にしても、１イテレーション中での数はそれほど多くないと予想できるので、制御できないほどのチケットは作成されないと思われる。
1-2,有効期限切れのチケット・放置されたチケット
スプリントプランニングで登録されたチケットは１スプリントですべてクローズされるはず。
残ったチケットはバックログ未完了になるので、振り返りで完了できない理由を明確にしたのち、再度振り分け（登録）される。
よって、放置されるのは最大でもスプリント期間のみで、それ以上になることはない。
有効期限切れについても同様
1-3,責任が重すぎるチケット
scrum でのタスク粒度は時間単位。先日のセミナーでは５時間以内が望ましい、とのことだった。
ということはそれ以上のチケットは粒度が大きすぎるので、タスク分割をすべきなのだと思う。
そうして、５時間以内の見積りになったチケットは責任が重すぎるということはないはず
1-4,停滞したチケット
僕も進み具合のパーセンテージが嫌いなので、0%か100%（やってないか、終わったか）、0%か50%か100%（やってないか、仕掛かり中か、終わったか）のほうがしっくりくる。
タスクには期限があり、それに合わせて朝会を行うので、停滞もないはず。
タスク自体の期限が２，３日になるようであれば、タスク分割自体を見直すべき
1-5,タスクがチケットに書かれない
タスク分割してないでしょ？朝会してないでしょ？
ほかのは
scrum の範囲外だと思うので特に書かない
｢アジャイル｣という言葉について
最近｢アジャイル｣という言葉自体があまり好きではない。
なぜかというと、視点の違うプロセスがあたかも同じレベルのように語られているように見えるから。
XP も scrum もアジャイルだけど、 XP は開発者よりのプロセスだし、 scrum はプロジェクト開発全体のプロセスだと思っている。
XP だけ適用してもうまくいかないだろうし、scrum だけ適用してもうまくいかないと思う。
それぞれをうまく融合することで成功確率が上がっていくんじゃないかな？
Wikipadia を見ても同列に扱われているので、これだと排他に見えてしまうのは気のせい？
TiDD はどちらかといえば XP のほうの部類だと思っていて、チケットをうまく運用するためのノウハウであって、これを適用すればプロジェクトがうまく回るわけではない。
タスクの分割の仕方や、タスクの処理方法は TiDD にはなく、それは scrum でカバーできる範囲だと思っている。
scrum と XP と TiDD をうまく組み合わせることで、みんな幸せになる確率もさらにあがるんじゃないかな？
最後に
僕は scrum についての深い知識があるわけでもなく、実践してるわけでもないので指摘があればどうぞー
