## 建立故事的時機
1. 由Scrum Master和Product Ower來寫故事。敏捷雖然是要提高大家的積極度或參與度，但是故事建立並不需要每個成員都參與，如果都參與寫故事會造成故事風格不統一，對整體評估和說明反而不利。
2. 故事建立要提前。Scrum Master需要提前安排好下次迭代開發的故事，並把需求轉化為故事，產品需求文件和故事基本可以同時送到團隊開發成員。我們上次開發是，一起過需求，然後給大家需求分析時間，然後列故事，對故事進行評估。這樣就造成一點不好，Scrum Master和開發人員同時拿到需求，都需要時間分析，而Scrum Master建立故事的時候，大家是沒事幹的，這個時間至少需要半天。所以Scrum Master需要提前把下次迭代的故事列到backlog裡面，下次迭代直接選取優先順序高的故事開發，更有利也更合理。
## 如何建立故事
編寫好的故事，關注六大特徵 INVEST：獨立的 (Independent)，可討論的 (Negotiable)，對使用者或客戶有價值的 (Valuable to Purchasers or Users)，可估計的 (Estimatable)，小的 (Small)，可測試的(Testable)。我們開發中的經驗是更注重，小的，獨立的，可測試的。
* 大的故事一定要拆分，別超過5天，否則故事到Done的時間過長，也不利於控制。
* 獨立的，避免故事之間的相互依賴，如果過大，按第一條拆分。
* 可測試的，表示對使用者有價值的一個流程，而不是通過頁面來劃分，很容易陷入這種模式，一個或幾個設計介面組成一個故事，這種看是明確的東西，其實隱藏了需求關聯性，也容易在開發中容易造成功能遺漏，比方說頁面之間的關聯功能。故事描述格式可以寫作，作為使用者，需要什麼功能，以便做什麼事情。比方說，作為使用者需求登入功能進入後臺管理。
## 時間預估
撲克牌，每人根據自己情況得出一個天數
如果估算不一致，通過最多和最少估算人說出自己的估算方式，避免遺漏，也避免考慮過多
不需要把故事的需求細節瞭解的太細，而且不要把細節或實現方式放到估算會上，故事細節由使用者和開發人員討論得出。
預估是估算，不可能每個故事都特別準確，但最終的整體時間是可參考的