開発においてストーリーを垂直方向に切り出すすることはストーリーがアプリケーションのアーキテクチャに縛られないようにするためのよく知られたアプローチである。チームのメンバはたいていそのトレーナーやコーチからストーリーを水平に切り出すと、アーキテクチャを前提にしてしまう、私たち開発者が必要だと思った機能を書いてしまう過剰生産（あるいは金メッキ）をしてしまう、そして最も重要な、進捗が見えなかったり顧客にとってのビジネスバリューを生み出さなくなってしまう、といった、数多くの問題を生むと警告される。より詳しくは、Mike Cohn氏のUser Stories Appliedを見て欲しい。
Antony Marcano氏はタスクは一般にストーリーを繰り返し水平に切り出したものであるという一つの興味深いねじれを持ち出している。例えば、"モデルにxを追加する"、"Viewを変更する"といったように。伝統的なスクラム/アジャイルアプローチでは、チームはスプリントのタスク時間数を見積もり、それをスプリント/イテレーションバーンダウンチャートに記録する。Anthony氏はこれはソフトウェアを開発する上での進捗の真の評価軸ではないと指摘する。
この問題に回答して、次のような指摘した人もいた。タスクではなくストーリーを減らせ 、タスクの時間経過ではなく速度を計測せよ。
Antony氏は書くストーリーの実装が成功したかどうかの合格基準を記録せよ、と提案している。これを行うために、合格基準をぼんやりとした記述から検証可能なものに変更する必要がある。例えば、“プロファイルを保存するためのリンクがなければならない” –> “新しいプロファイルを作成する”のように。いったん合格基準がテスト可能になれば、合格基準のためのテストがあるかどうか、およびそれらがパスしたかどうかを記録することができる。
Jason Gorman氏はタスクトラッキングは完了の意味を間違えることにつながると気づき、前述のものと同じ問題に言及した。
“タスクは"やり方"であり、タスクという視点からはユーザストーリーの90%完了しているが、ユーザにはまったく価値を提供できていない、ということが実際に可能である。そのため、タスクを使って計画し、イテレーションを記録することで、悪名高き誤解である"90%完了" 症候群に陥る可能性がある”
Jason氏のアプローチはAntony氏が述べた問題の1つの解である。Jason氏はチームに1つのストーリーに対するそれぞれのテストの複雑さを見積もらせるだろう。チームは合格テストのうち提供できたものを得点化して記録する。
どういう切り口から考えても、タスク時間を記録するということは時代遅れであり、その代わりに顧客に提供した価値を測定する方法を見つけるべきである、というのが共通認識であるということは確かである。