でSCRUMのアプローチ明確にする必要があり3つの文書を：
1製品バックログ
2sprintバックログ
3バーンダウンチャート
プロダクトバックログは、プロジェクトのニーズを実装する必要があります記載されている、方法が記述されたユーザーストーリーを使用するための需要は、ユーザーが開発者に伝えるために、ユーザストーリーのニーズを表現するためにおなじみの用語を使用して短い物語である、ない開発者は言いますユーザーストーリーへ。それは物語であるので、誰かがそれがあると言って誰が、と言うだろう異なる内容を有していてもよく、あなたが話すたびに変更されますが、本来の目的なので、話自体はある程度の柔軟性ですがあるはず、製品の所有者が懸念していますA。物語は、標準フォーマット、Iコール三段論法の物語、それの3つのセクションを有することができますか？
1ユーザーの役割
2機能が必要
客観3
たとえば、Aの話があります：
主婦として、私は必要なので、あなたが私の中で楽しまことができ、30平方メートルのレストランを食事を10人の友人。
ユーザーの役割は、主婦ある30平方メートルのレストランを楽しま、機能要件である10人の友人が食事をあなたがこの機能を必要とする理由です。この三段論法の話を過小評価してはいけない、我々は慎重に、各セグメントの役割を熟考する必要があります。ユーザ関数は、あなたがそれを削除することができるかどうか、明確でない場合は、ユーザーの役割は、この機能を使用する人を示していますか？ユーザーの役割は、それを必要とする優先順位の低いかどうかは重要ではありませんか？あなたは関数が明確な目的は、それを削除することができるかどうか、ではない場合、問題を解決し、この機能を必要とする理由目的は説明しますか？目的は、この需要はそれに低い優先度のものとすることができるかどうか、重要でない場合は？
優先順位？はい、私は繰り返し、優先度のニーズに言及しているが優先されなければなりません！誰が、優先度のニーズを分割しましたか？製品の所有者！どのように優先順位をつけるには？商業的価値によると！顧客によると、エンドユーザーの商業的価値を優先します。それの商業的価値の大きさを区別するためにどのように？あなたはこの要件を達成しない場合、顧客は一種の人々の、どのような不満を持っていると満足していない場合は遅く、この要件を実装した場合、質問をしますか？どの程度満足していませんか？一部の専門家はまた、場合、実際には、必要のない、より専門的なアプローチを提案し、製品の所有者は本当に有能で、私は彼が経験的に、優先度に分けることができると信じています。
そのような言葉は、それを完全に記述するだけであれば？実際に、あるが4番目の段落、テスト・ポイントと呼ばれる、そのユーザの受け入れ基準のストーリーやユーザストーリー、完全に製品の所有者は、製品の所有者は、最初の3つのセグメントに完了することができ、及び通信処理のチームメンバー、ステップバイステップ豊かな音の許容基準。あなたは、このようなレストランを実装する場合、我々は、先に述べたその話には、例えば、ある2メートル、幅15メートルのレストランでは、主婦はどのようにしたいですか？彼女の精神的健康は、それが推定されている場合母、彼女はすぐにあなたが飛び降りるてみましょう！彼女の精神的不健康場合は、彼女が飛び降りるだろう。もちろん、このような現象は、アジャイル手法では発生しません、あなたの開発の過程で、製品の所有者は、いつでもあなたと通信し、通信中に、製品の所有者もこのメッセージを伝え：
1私はこのレストランがあると思います5メートル; * 6メートル
2私はこのレストランが明るい願っています。
3私は台所の近くにこのレストランを願っています。
4 ......
これは、受け入れ基準です！別の見方をしてもよいし、どのように受け入れられるの観点から説明します
この部屋の量が1の場合、私は意志5メートル* 6メートル。
私はライトをオンにしないでください、そして、あなたがポーカーのスーツやポイントを見ることができ、日中この部屋でポーカーをプレイするならば2 CECE。
CECE 3私はダイニングルーム、いくつかのステップに台所から行く必要があるでしょう。
4 ......
物語はそれを行う方法を受け入れ基準を言及していない場合は？明確な受け入れ基準まで、後半にそれを実現し、それを実現しないでください。
これまでのところ、私たちは実際にの話では、製品バックログを含む5つのセクション：
プロダクトバックログ=需要 +優先
=ユーザーストーリー +優先 +許容基準
ユーザロール= +機能 +目的 +優先 +許容基準
受け入れ基準を選び出し一部の専門家は、私が受け入れ基準は、要件の一部であることを信じているが、それを記述する方法のため、それはまだ、製品バックログ、それの一部。
私は「機能的」という言葉に言及しているように、非機能要件に言及し、実行する方法の非機能要求がある場合にしませんか？二つのアプローチ、物語に、物語の中で説明した許容基準は、第二の書き込みにある場合は、1つは明らかに「技術の話を、」これらの物語に注意を払うに開発者を思い出させるために、白羽することができ、話はないかもしれない作られた製品の所有者A。
ユーザーストーリーのために我々は、以下の理想を実現するために願っています：
1）独立。話間の依存関係を避けるようにしてください、話の間の依存関係がストーリーの間で取り決めの依存関係を開発する際に考慮されるためには、困難を優先になりますがあります。
2）ネゴシエートすることができます。物語は、物語は弾力的である、物語は言う必要があり、書面による契約または需要が達成されるべきではなく、交渉です。
3）利用者や顧客の貴重な。各顧客またはユーザーストーリー貴重が書き込みの話にユーザーを可能にするためであることを保証するための最良の方法。
4）予測。開発者は、として必要な符号化を達成だけでなく、物語の（少なくとも、おおよその推測）時間スケールを予測することができるはずです。
5）短く、簡潔。一般的に、反復サイクルの物語が達成可能でなければならない、と我々は短周期の繰り返しを提唱します。
6）テスト容易性。書かれた物語は、あなたが受け入れ基準を定義することができ、テスト可能でなければなりません。
これが理想的であることに注意してください！
プロダクトバックログは、プロジェクトの進行の過程で変更され、唯一の製品の所有者は、この文書を変更する権利を持っています。あなたが使用することができ、それを記述するためにEXCELファイルを、アジャイルプロジェクト管理ツールの数はまた、あなたが維持する、またはそのような追跡ツールなどのいくつかの欠点を、使用するために使用することができ、最も簡単な方法の最も直感的には、ステッカーを終了するようにJIRAを使用することが直接的です誰もが見ることができるように、いつでも、理事会事務局に掲載！