スクラムでは一般的に，要件は ユーザストーリー で表される。では ユースケース の使用も認められるだろうか？ 認められるとすれば，どのような状況で用いるべきだろうか？
スクラムでユースケースを使用する必要があるのでしょうか？ 議論や共同作業，あるいはテストケースの開発には，適切に記述されたユーザストーリーがあれば十分ではないか，と私は思います。
そもそもスクラムでは，ユースケースではなく，ユーザストーリーを使わなければならないのだろうか？Roy Morien 氏はそれを否定する。
スクラムの要件定義作業では，対面による会話，定期的なスタンドアップミーティング (どうしてもというなら座ってもよいですが)，スプリント計画セッションなどを推奨してはいますが，特定の手法を必須と決めてはいません。ユーザストーリーの解析が必要であったとしても，全般的な共同作業の実施と透明性以上のものは求めていないのです。ガイドラインに沿ってさえいれば，実際に何を行うかはあなた次第でしょう。
だとすれば，ユーザストーリーの使用が望まれる状況とはどのようなものだろう？Charles Bradley 氏は次のように推奨している。
一般論として，新たにスクラムに移行するチームについては，当初の数ヶ月間は以前に経験のある何らかの要件プラクティスを使用することを勧めます。新しい要件収集プロセスをすべて学ばなくても，スクラムの習得は十分にハードな作業なのですから。
氏は次のようにも書いている。 "[...] スクラムガイドによると，大半のスクラムチームが [ユーザストーリーを] 採用する一方で，‘活動において特にミッションクリティカル，あるいはライフクリティカルであること’ を要求されるチームは [ユースケースを] 用いる傾向があるようです。" しかし Adam Sroka 氏は，このアプローチに異議を唱えている。
"クリティカル" なアプリケーションにはより詳細な資料が必要である，というのが従来の発想です。これは間違っていると思います。クリティカルなアプリケーションに必要なのは，より多くの (そして良質な) 検証作業なのです。それを実施するには，徹底的に自動化されたテストが必要です。ほとんどの "クリティカル" なアプリ開発チームがそれを行っていないことが，私には理解できません。
しかしユースケースドキュメントの提供する価値は，あるいは純粋に機能的な領域以外にあるのかも知れない。Charles Bradley 氏が次のように書いている。
ところで私は，航空業界で働いていたことがあります。業務に関する詳細な業界知識 (どの規制に何が必要か，など) を持たなかった頃のドキュメント作業から得た印象は，ドキュメント作成の目的としてプロセス監査などは比較的小さく，航空事故の理由と責任所在の検証 (規約あるいは訴訟対策として) に関するものが大きい，ということです。この例のように，(会社を保護するような) 特定の役割を持つドキュメントに関するあなたの立場を証明 (責任の回避) するためには，ユーザストーリーよりユースケースの方が有効かも知れません。
アジャイル方法論に関するすべての面と同じように，ユースケースが組織にもたらす価値については十分に検討する必要がある。必要な労力に対して，得られる成果は十分なものだろうか？ 何しろ Ron Jeffries 氏が書いて いるように，"ユースケースを完全にマスタした人はめったにいない" のだ。あなた自身，ユースケースを書くのがうまくないと認められるのなら，組織に対してもっと貢献できる方法が他にあるのではないだろうか？