Mike Burrows 氏によると，
大きな機能をもっと小さな機能のリストに展開 (分解) することはよくありますが，後になってそれを元々のチケットにまとめ直す(collapse)というのは，あまりないような気がします。これをどう思いますか？
- 当たり前？
- 良いこと？ (理由は多々ありそうですが)
- 悪いこと？ (これも同じ)
- 条件次第？ (どんな条件でしょう？)
kanbandev グループ の見解は，小さな機能を大きな機能にまとめ直すことにはあまり価値がない，という方向で概ね一致しているようだ。Kurt Häusler 氏が 次のように書いている。
展開したりまとめたり，というのは感心しませんね。でもシステムにまだ入っていない初期の段階で，なおかつプロセスを通じてその状態が保たれるのなら，大きな要件を多数の小さなストーリに展開するのも悪くはないでしょう。トランザクションコストの削減が困難だから，顧客が "未完成の" 機能をテストできないから，あるいは "規模と複雑さ" を求める人が多いから，といった理由で，もっと大きな MMF やミニプロジェクト化などを安易に導入するくらいなら，試してみる価値はあると思います。いつもうまく行くとは限らないでしょうけれど。でも単純明快なバーティカルスライス，バリューストリームを通じて これが一番でしょう (FTW)。
Ron Jeffries 氏 からは ，
かつての XP では，ストーリをタスクに分割することが推奨されていましたが，最近はそうでもありません。代わりに，小さなストーリにスライスすることがよい，とされています。XP には "まとめる"，という明確な概念はありません。必要ないからです。
一方で Siddharta Govindaraj 氏は，まとめ直しに一定の意義を認めている。
開発チームに限った観点なら，それでもうまく行くでしょう。ストーリをスライスしてひとつずつ提供すればよいのであって，まとめ直す必要はありません。しかしもっと広い視野で見るときには，流れ全体の中での多数のステップという考え方が，大規模な機能には有効です。つまり，開発レベルでは小さなストーリで展開したとしても，大きな機能が次のステージに移るときには，それらをもう一度まとめ直すことも必要なのです。
これに 対して Ron Jeffries 氏は，
次のステージというのは，どのようなものですか？ 例えばスクラムや XP なら，イタレーションごとの成果は，ソフトウェアの拡張機能として (必要なドキュメントもすべて含めて) 完結しているはずです。これは kanban の観点，つまり開発側の観点から見たものですけれど，それでも展開／まとめ直しを十分できていますし，ムダ(waste)やバッファ，遅れといった除去可能なものも，ほとんど完全にモデリングできます。
Paul Beckford 氏の 意見では，
ここで重要なのは，インクリメント，フィードバック，イタレーションを小さくすることです。それさえ出来れば，まとめ直しという発想は，最小のインクリメント単位 (例えばひとつのスライス，これは私にとって許容できる最小基準であって，およそ半日程度です)以外のどの抽象レベルにおいても，意味をなさないでしょう。