ユーザーストーリーを採用する場合、要件の指定が不要であることをチームにどのように説得できますか？
重いSRS（ソフトウェア要件の仕様）ではなく、軽量な方法で利害関係者の「意図」を捉えるために、ユーザーストーリーを採用することを計画しています。ただし、彼らはストーリーの価値を理解していますが、すべての属性、優先度、入力、出力、ソース、宛先などを備えたSRSのような言語にストーリーを「変換」したいという要望がまだあるようです。
ユーザーストーリーは、アーティファクトのような正式なSRSの必要性を "排除"するため、SRSを持つことのポイントは何ですか？システムの機能要件を取得するためにユーザーストーリーを採用した場合、SRSは「排除」されることを私のチーム（ちなみに、教育と実践の両方で非常に有能なCSスタッフ）にどのように説得する必要がありますか？ （NFRなどもキャプチャできますが、それは質問の意図ではありません）。
だからここに私の「ワークフロー」の引数があります：初期要件をユーザーストーリーとしてキャプチャし、後でユースケースに精巧化します（これは低レベルでドキュメント化する必要があります（つまり、UIプロトタイプ/モックアップとの相互作用を説明し、成果物です）展開）。したがって、ユーザーストーリーからSRSへのユースケースではなく、ユーザーストーリーからユースケースへの移行。
現在、職場でユーザーストーリーをキャプチャしている場合（ある場合）、ユーザーストーリーが存在する場合にSRSが存在しないことを「主張する」ことをどのように提案しますか？
赤ちゃんのステップ。しばらくの間、SRSの作成を続けます。次に、会議を呼び出し、それらがまだ目的を果たしているかどうかを話し合います。まだ誰も読んでいますか？それらに費やされた時間は正当化されますか？より軽量になる別の中間ステップはありますか？
あなたは決して知りません、あなたはあなたが間違っていることに気付くかもしれません。アジャイルマニフェストを思い出してください。「包括的なドキュメントよりもソフトウェアを活用する」の方が価値がありますが、後者にはまだ価値があります。
しかし、私の推測では、ユースケースとユーザーストーリーがどの程度密接に関連しているかを見ると、重いドキュメントを書き続けたいという欲求が失われることにすぐに気付くでしょう。
エピックはプレースホルダーです
ほぼすべてのアジャイル方法論では、Epicsの概念は要件仕様に必要なものと同じくらいになります。プレースホルダーはそのレベルで必要なものです。これらのエントリには常に優先順位が付けられます。要件の優先度が長期間低くなるか、実装されない場合でも、詳細は無駄な作業になります。それを文書化し、その周りの文書を管理することは、時間の無駄です。 YAGNIは、要件アクティビティおよびコーディングアクティビティにまで及びます。
ツールはあなたの友達です！
適切なツールを使用してユーザーストーリーを収集および管理する場合は、それらから要件仕様を生成できます。要件の仕様は一時的なartifactとにかくドキュメントであり、生きたドキュメントではなく、時間の経過に伴う要件のスナップショットです。そして、現実と同期することはありません。
アーティファクトを自動生成
適切なツールからエクスポートできるユーザーストーリーは、静的アーティファクトドキュメントよりもはるかに価値があります。個人的に私は Pivotal Tracker がユーザーストーリーを追跡することを好む、Pythonストーリーに関する詳細な開発者メモなどが含まれています）、ライブデータは常に静的データよりも優れています。
Wikiは、すべてのストア/要件、およびそれらの完了状態と優先順位の詳細とコメントおよびその他のメタデータを含むライブドキュメントになりました。
Sharepointの巨大なWord文書よりもはるかに優れており、絶えず電子メールで送信され、更新されることはないため、全員が異なるバージョンを使用し、他の全員と同期していないことが保証されます。
ユーザーストーリーはユースケースよりも豊富です
[〜＃〜] why [〜＃〜]と書かれているため、ユースストーリーはユースケースよりもはるかに価値があります。
ユーザーストーリーの形式：As a [ROLE] I [ACTIVITY] so that [WHY]は、The System [shall/shall not/may/must] perform [action]（アクションがフローチャートの場合）のようなユースケースよりもはるかに表現力があります。
ユーザーストーリーを使用すると、[〜＃〜] who [〜＃〜]何かを実行したい場合、[〜＃〜] what [〜＃〜]を使用できます。彼らはしたい（複雑なタスクのより詳細な図/ドキュメントを指すことができます）そしてあなたは最も重要な部分を持っています[〜＃〜]なぜ[〜＃〜]彼らはこの活動をしたいです。
あなたが最初のものを持っているなら、2番目のものは完全に冗長で、せいぜいノイズだけです。ウォーターフォールの方法論による従来の正式な要件仕様は、アジャイル環境では機能しません。
最終的には
あなたの経営陣が変化を約束しないと、新しい方法論で成功することはできません。私は年間1,000億ドル以上の会社で働いてきましたが、アジャイル/スクラムへの移行に踏み台を踏みませんでした、彼らはただ、会社全体がこれに移行しています、ここが新しい方法です。新しい方法のトレーニングが始まるとき、これから使用する新しいツール、ここからこの方法で作業を開始する日付です。それは彼らのために1年未満で働いた。私はこれを小規模の企業に実装することに取り組み、同じ成功を収めました。
コミットメント
baby stepsの実装は、変更内容に関係なく、失敗のレシピです。それは彼らが静かに同意せず、失敗のためにあなたを受動的に積極的に設定しているのは管理者のためのコードワードです。彼らは言っています私はこれをコミットするのに十分とは思わないので、失敗した/成功しないためにあなたに十分なことをさせますそれはうまくいきませんでした、そして彼らが管理していた彼らのやり方はずっとうまくいきました。部分的な取り組みは最終的に失敗につながります。
あなたの場合、彼らはおそらく静かにユーザーストーリーを信じていません、そして両方をしばらくすると、彼らはそれが役に立たないユーザーストーリーでありSRSではないと主張し始め、ユーザーストーリーの書き込みを停止するようにプッシュします、前方ではなく後方に移動します。
私はユーモアを使ってみます。
http://www.halfarsedagilemanifesto.org/ から始めます
これについてしばらく話します（diversion）
そしてその中での衝突が本当に意味することについて話します（公開討論）、
それからしばらくして、組織に移ります（pivot）
そしてSRSを調べ、それが新しいプロジェクトのセットアップで意味があるかどうかを調べます。
次に、アプローチre：SRSの変更についての議論で（またはおそらく別の会議で）結論を出し、コンセンサスがあるかどうかを確認します。
結局のところ、あなたは予算とビジネス人々にサービスを提供しているという制約もあるので、何が使われるかについて少し固くなっている点があるかもしれませんが、これは実際には業界、会社の規模、組織的要因、その他多くに依存します他のそのような要因。