Michael Sync氏は1つ聞きたいことがある。それは大きなプロジェクトや大きな機能をどう見積もるのかという疑問である。
結局あとで変更する必要が生じることになるので、1つか2つ以上のスプリントの見積もりはすべきではないと聞いたことがあります。しかし現実問題としてこのやり方は機能しません。ターゲットとなる日にどんな機能を間に合わせ、優先順位をどうつけるかを交渉するためには、前もってプロジェクト全体かいくつかの機能を見積もる必要があるのです。より正確に見積もるためには、スプリントをつくる前にユーザストーリーをタスクに分解する必要があります。そのためにはどのようにそれらを扱い、見積もるべきでしょうか？
Peter Bell氏は見積もりとコミットメントをきっちり区別することは重要であるとしている。
あなたが求められているものは見積もりですか、それともコミットメントですか？見積もりはその時点で利用可能な情報に基づいて行われる裏付けのある推測です。見積もりは常に高いか低いかのどちらかであり、一般に複雑なソフトウェアを構築する際は低く見積もられます。それはコミットメントとは違うもので、コミットメントとして利用することはできません。
スクラム開発メーリングリストでの共通認識は、プロジェクトの見積もりの努力はたいして有意義な活動ではなく、多くの時間を割くべきものではない、ということのようだ。"woynam"氏は次のように書いている。
本当にこれ（訳注：やらないことを表現すること）をするためにはどれくらいのコストがかかりそうかを心配することをやめ、スコープが変化する活動に対する取り組みを行うことです。あなたが使うことのできる金額を知っていて、投資する時間がどのくらいかも知っているのなら、唯一の変数はお金を得るためにどれだけの機能を優先づけし開発することができるかだけです。重要なことは、見積もりを"やめて"ももっとも重要な機能を最初に開発することができるということは変わらない、ということです。
George Dinwiddie氏は次のように書いている。
もし利益や損失が正確で精密なコスト予測に依存するものであるなら、そもそも間違った製品を選んでしまっているのです。利益が出る可能性があまりに小さいということです。多くの場合、組織のトップにいる人々はこのことを理解していますが、中間の管理者は理解していない、と私は感じています。
Ron Jeffries氏はこれに対するもっとも強烈な見方を示している。
見積もりはたいていの組織ではよいことではありません：それはコミットメントとか割り込みとして利用されます。また、チームが何をどのように成し遂げるかを深く見ることをせず、どのくらいの作業を引き受けるかを決めポイントや時間のつじつまを合わせるための機械的方法に頼ることになります。[...]
私は"2、3人の人による2、3日の作業"を超えたストーリーを見積もることをまったくお勧めしません。もちろん、その小さな見積もりもある種の見積もりであることは確かですが、それは濫用しづらいものです。
[...]
私はチームに数週間の大きなストーリーに見積もらせることは好きで、それをやらせたあと合計します。この作業によってプロジェクトの大きさがおおよそつかめます。これは約束するためのものではありませんが、それを利用して「NドルとMヶ月を使っても、出荷する価値があるものを得られるか？」というような重要な質問をすることができる基準となり得るのです。