別々のユーザーストーリー/製品バックログアイテムで同様の機能を処理するための最良の方法は何ですか？
TFS 2010SCRUMテンプレートを使用しています。
だから、私がこれらのユーザーストーリーを持っているとしましょう：
ユーザーとして、パートナーページから直接連絡先を追加できるようにしたいと考えています。
ユーザーとして、プロジェクトページから直接連絡先を追加できるようにしたいと考えています。
設計上、連絡フォームは同じである必要があり、機能も同じである必要があります。したがって、ユーザーがいずれかのページから[連絡先の追加]ボタンをクリックすると、ポップアップウィンドウが表示され、ユーザーは新しい連絡先を追加できます。開発と設計は類似しているため、これらのストーリーは両方とも類似したタスクを共有する必要がありますか？機能を別々のストーリーに分割する必要がありますか？
更新：それで、これを書くことはより受け入れられます：ユーザーとして、私はサイトの任意の領域から連絡先を追加したいので、speicifcの連絡先入力ページに戻る必要はありません。
次に、そのストーリーに必要な機能を提供できますか？
開発と設計は類似しているため、これらのストーリーは両方とも類似したタスクを共有する必要がありますか？
はい。
機能を別々のストーリーに分割する必要がありますか？
いいえ。ストーリーは機能ではありません。それらは物語です。
ストーリーをサポートする機能を発明します。それは「デザイン」と呼ばれています。
ストーリーからコードを書くだけではありません。
まず、あなたは思います。次に、いくつかの設計を行います。おそらく、既存のコードをリファクタリングします。おそらく、既存のコードを追加、変更、または削除します。おそらく新しいコードを書いてください。
しかし、ストーリーとコードの間に愚かな1対1のマッピングはありません。
ストーリーとコードの間で実際の設計作業を行う必要があります。
「ユーザーとして、サイトの任意の領域から連絡先を追加したいので、speicifcの連絡先エントリページに戻る必要はありません。」
番号。
ユーザーとして、連絡先をすばやく効率的に追加したいので、[連絡先をすばやく効率的に追加することの価値を示すためにここに何かが表示されます]。
ユーザーストーリーで効率の価値を示したら、「サイトの任意の領域から連絡先を追加するのが良い機能です」などの追加の実装情報を書くことができます。これにより、この機能を構築するための設計上の考慮事項やその他の考慮事項が生じる可能性があります。
実装のどれも物語の中にありません。脚注や付録、補遺など、ストーリーに付随する資料があってもかまいません。しかし、ストーリーは「純粋」であり、適切なビジネスケースとビジネス価値を述べている必要があります。
まず、ストーリーは機能ではありません-私がまだ入力しているときにS.Lottが指摘したように-ストーリーは機能の受け入れ基準を定義します。したがって、表面的には、これらのストーリーの両方が同じ機能に適用されるように見えます。
しかし、私はこれらの物語を書いた顧客に戻って、理由を尋ねます-
As a user I want the ability to add contacts directly from the Partner page
SO THAT [business reason]
As a user I want the ability to add contacts directly from the Project page
SO THAT [business reason]
ビジネス上の理由が同じである場合は、anyページから直接連絡先を追加できることが有用/必要かどうかを検討してください。その場合、ストーリーは1つだけになります（1つの機能に対して）-言い換えると、これらの2つのストーリーは、すべてのページから利用できる機能について、「ツールバー」または「共通メニュー」機能を意味する場合があります。
ただし、ビジネス上の理由が異なる場合は、2つの指定不足機能がある可能性があります。