スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて，決着の付かない議論が長く続いている。どちらの陣営も，自分たちのアプローチが相手より優れているとする根拠をいくつも持っているようなのだ。Mike Cohn 氏が ユーザストーリーをタスクに分割して，それを元に時間見積を行う方法を好んで使用すれば，それに対して Jeff Sutherland 氏が 氏自身が関わった最高のチームでストーリーポイントを使ってバーンダウンを行った例をあげる。他にも多くのアジャイリストたちが，自らの好む方法とその理由について意見を表明している。
Mike Cohn 氏はスプリント計画でストーリーポイントを使用することを好んでいない。ストーリーポイントがどちらかと言えば長期的な測定基準であって，短期作業には向かないと考えているからだ。彼の意見では，
シーズン中盤のバスケットボールチームを想定してみましょう。チームはこれまで41試合で平均98得点をあげています。彼らが「今シーズンの残りゲームでも平均98点は得点できるだろう。」と思うのは適当かも知れません。でもある試合の前に「僕らの平均得点は98点だから，今夜も98点取れるさ。」と考えるのは間違っています。これが作業速度は長期的な予測因子としては使えるが，短期的な予測には不向きである，と私が考える理由です。
Tara Lee Whitaker 氏はこの意見に反対で，ストーリーポイントを短期的な測定方法であると考えている。彼女によれば，
個々のストーリーが‘正確に’見積するのに十分に小さく，かつテスト確認書を作成できるだけのテスト性を持っているならば，それをより小さな部品にブレークダウンしたり，時間単位で再度見積を行ったりしても，大した利益は得られないでしょう。
しかし，ストーリーを時間で見積ることに関して大きな懸念を持っている点では，意見が一致していて，
時間でバーンダウンするアイデアについて私たちが最初に議論したとき，私が心配に思ったことが主に２つあります。ひとつはバーンダウンが示す早期警告サインを利用できなくなるのではないか，という点，もうひとつは問題に気づくのが遅れたときに，あるストーリーが予想より多く時間を費やしたこと以外何も発見できないのではないか，という点です。
Jim Schiel 氏はストーリーポイントと時間の両方でスプリント計画を行うことは可能かも知れないと考えている。しかし時間単位での見積への投資に対する見返りは，それを重要な実行候補にするほど高くはない。彼の意見では，
２ストーリーポイントからなる PBI(Product Backlog Item) を10個処理する Scrum チームを考えてみましょう。作業がすべて完了すれば，彼らはスプリントあたり 20 ストーリーポイントの作業速度を達成したことになります。彼らは次のスプリントでも 20 ストーリーポイントを目指すでしょう。けれどもそのスプリント中に何かが起きて，多少大きくなったり小さくなったりするかも知れません。このようなことがスプリントごとに繰り返されて，チームの作業速度の平均は18～22あたりになるでしょう。時間見積でこれと同じことができるでしょうか？ 答えはYESです。しかしそれを実現するには相当な費用が必要になるはずです。完成して動作するソフトウェアと非常に正確な見積，あなたならどちらにお金を払いたいと思いますか？
Jack Milunsky 氏もストーリーポイントの重要性を主張して，次のような利点をあげている。
- 普遍的測定値 – ストーリーポイントはチームを越えた共通の測定値である。経験やスキル，チームの個人によって振れることはない。
- 安定した状態 – ３つないし４つのスプリントをこなせば，チームは安定した状態になり，プロダクトオーナがバックログに安定した状態のストーリーポイントを詰め込むのも簡単になる。それだけのことだ。
- ゾーンに入る – チームが一度安定すれば，ビジネスは技術チームを信用する。これがチームを高いモチベーションと自信のゾーンへと押し上げる。
Tomas Björkholm 氏はストーリーポイント方式を推進する理由として次のものをあげた。
- 理由その１，見積はストーリーのサイズを述べるものであって，実装に掛かる時間を表すものではない。
- 理由その２，人日のサイズはチームのパフォーマンスによって変わるものだ。ストーリーポイントはより一定している。
- 理由その３，相対的な見積が絶対的なものよりも正確であることは証明されている。人日は時間測定値なので，相対的に使用することが可能ではあっても，絶対的な見積により向いている。
さらに加えて，
Pomodoro Technique に関するスピーチで Staffan Nöteberg 氏は，多くの人々が見積を実時間で算出することを不快に感じていると語っています。私だってそうです。不快な気持ちの人の生産性は低いから，人日での見積もりは非生産的なのです。
Mike Cohn 氏はストーリーポイントと時間数の間に線形相関関係がないことを指摘している。氏によれば，各ストーリーごとに標準偏差の倍数を基本とした分布範囲があるという。
１ポイントは x の平均と標準偏差の倍数の分布に等価です。当然２ポイントのストーリーにもこれが当てはまりますし，それ以降も同じです。
そのために，ストーリーポイントで計測された作業速度が既知であったとしても，チームが仕事を完了する日を特定してステークホルダーに告げることはできない。範囲が必要なのだ。
ここで範囲と呼ぶのは，「プロダクトバックログのすべての項目を完了することができます。ただし完了するのは５月か６月頃でしょう。」というような日付範囲の場合もあれば，「ご希望どおり５月２０日に完了します。それまでにプロダクトバックログのここからここまでにあたる，120～140の範囲内のどこかの数のストーリーポイントを獲得できるでしょう。」というスコープ範囲の場合もあります。
Mike Cohn 氏はまた，ある意味リーン主義の一種である comminent-driven sprint planning (責任駆動スプリント計画) とでも呼ぶべき別の手法を提唱もしている。このアプローチでは，チームはストーリーポイントや作業速度については議論しない。彼らは単にバックログタスクから高い優先度の項目を取り出し，彼らの生産能力ごとに時間で見積る。それから自身の責任を果たすのだ。
このようにスプリント計画については，どちらの技法にも賛否両論がある。結局はチームが納得できる方法に落ち着くことになりそうだ。あなたの好みはどちらだろう，そしてその理由は？