多くのアジャイルチームが、ストーリーポイント（Story points）とコンプレキシティポイント（Complexity points）という用語を交換可能なものとして使っている。そして、アジャイルチームは、これらが複雑さや相対的な大きさに基づいているというだけで、時間よりもすぐれていると思い込んでいる。Mike Cohn氏は、あるフィーチャー（機能）を開発する際に、ストーリーポイントを複雑さを表すのに使うのは間違っており、それらはすべて労力に関係するものだと述べている。
Mike氏は次のように言う。
私がこんなことを言うのは、ストーリーポイントはユーザストーリーやフィーチャーを開発するための労力ではなく、その複雑さに基づくべきだと考えているチームがあまりに多いことがわかったためです。こうしたチームはたいてい「ストーリーポイント」のことを「コンプレキシティポイント」とラベルを貼り替えて使っています。聞こえがいいのかもしれません。おそらくその方がしゃれた感じがするのでしょうね。しかし、これは間違っています。ストーリーポイントはフィーチャー開発における複雑さとは関係ありません。ストーリーポイントはフィーチャー開発に必要な労力に関係があるのです。
Mike氏は、1000枚の切手をなめることと単純な脳外科手術という2つのバックログアイテムを比較するという興味深い例を挙げた。これらには複雑さに非常に大きな違いがあるが、同じくらいの時間がかかるので同じストーリーポイントを与えるべきだと彼は言う。
Scrum Developmentグループでも同様の議論があり、Adam Sroka氏は、ベロシティの測定を十分安定させるためにチームには時間に近いものが必要だと述べた。また、ストーリーは相対的な労力と相互に関連すべきもので、労力は時間に相当すると述べている。
しかし、だからといって、チームは時間で見積りをするべきだと言っているわけではない。多くの人により、時間での見積りはムダで不正確なことがわかっている。Mark Levison氏はこうコメントした。
見積りはムダです。タスクを時間で見積るのはまったくのムダです。始めてしまった方がずっといいのに、みんな細かいことを議論するのに時間を費やしています。ストーリーをポイントで見積るのもムダなことです。プロジェクトの進捗を予測可能で透明性のあるものにするには、ストーリーはだいたい+/-1の差で同じ大きさでなくてはなりません。ほとんどのチームにとって（成熟度によらず）、これは難しいと思います。ですから、ストーリーポイントにこだわるのです。
Jeff Sutherland氏は、時間での見積りと比べて、ストーリーポイントの方を強く支持した。Jeff氏は次のように言う。
ストーリーポイントは時間と比べると、速くて、すぐれていて、コストがかかりません。非常にハイパフォーマンスなチームは時間での見積りをすっかりやめています。それはムダで、自分たちをスローダウンさせるものだと見なしているためです。
Mark Kilby氏はアジャイルに不慣れな人がストーリーポイント = 労力 = 時間とは思わないよう確認するためにコメントした。Mark氏は、ストーリーポイントを決めるときには労力は重要だが、不確かさも十分検討しなければならないと言う。Mike氏はポイントと時間は等価関係にないことを認めた。
おそらく、こういうことです。ストーリーポイントは、労力、リスク、不確かさによる関数、すなわち SP = f(E, R, U) なのです。（もし望むなら、これを複雑さのひとつと呼んでも構いません。それは重要なことではありません。） ストーリーポイントはそれ関係した労力の見積りだと考えるのです。リスク、不確かさ、複雑さ、不安、その他みなさんがここで話したことが盛り込まれます。ただし、予想される労力に影響を及ぼす範囲内に限られます。複雑だけれども、その複雑さがフィーチャーの実装時間に影響を及ぼさないのであれば、その複雑さは見積りに影響を及ぼさないはずです。— それが、かけ算、足し算する数のリストで言いたかったことです。
したがって、ストーリーポイントは労力に基づくべきであり、労力には、リスク、複雑さ、不安などの要因が考慮されるべきだ。重要なことは、答えるのにストーリーポイントが役に立つ疑問について理解しておくことだ。Mike氏は次のように表現した。
見積りのゴールは、「いつ完了するんですか？」や「期日までにどれくらいの機能ができるんですか？」という疑問に答えることです。もしこれが正しければ、どんな単位で見積ろうとも、どんなアプローチをとろうとも、それは時間に関係がある必要があります。