Artifact，Scrum 文件管理
- Vision
- 軟體的遠景、願景
- User Story
將期待及需求明確化
- 將 Vision 具體成可被執行的項目
- 以使用者角度思考，軟體能帶來什麼功能，使用者能獲得什麼好處
- 列出這些功能，形成一個個的 story （亦稱為 User story）
- Product backlog
- 待辦清單
- 待辦清單中的項目，即稱為 PBI (Product backlog item)
- 從價值導向來評估重要性，進行優先順序排序
- 計算 story point
| Importance | Story topic | Notes | How to test | Estimate |
|---|---|---|---|---|
| 重要性 | 目標主題 | 註解 | 如何測試，如何Demo | 完成此所需的 Story point |
story point:
**使用相對數字 **
估算一件事情，不容易精確評估出所需要的工時，但卻可以輕易說出他的相對大小
定義出相對大小之後，也能讓我們能更簡單的理解專案
例如，儘管各品牌出的尺寸差異仍然存在，但是仍可以透過相對SIZE 理解某一品牌，哪個尺寸最適合你
估算 story point 流行使用的是改良版費氏數列 (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100)
避免陷入連續數容易產生的糾結 (例如 在13, 14之間拿捏不定 )
通常會再搭配另外兩張牌：咖啡牌，問號牌 咖啡牌：表示需要中間休息一下 問號牌：對內容有疑問，不了解或不清楚，仍無法估算
延遲決定決策
Story point 是一種延遲決定的策略，需要到實際在 Sprint backlog 列出 task 時，才會推估出實際的時間
估算 story point
以建構後台為例，假設有五個單元要製作，功能都是CRUD
首先先推算出製作一個單元所需要的時間，就能以此類推的擬定出其他四個，就能取得總和
在估計story point 時，story point 單位為相對數值（非時間），
假設每個單元功能複雜度不一樣，以一個最基本的 CRUD story point 定義為 3，可以這樣估：
| 單元功能描述 | story point |
|---|---|
| 第一單元為 CRUD | 3 |
| 第二單元為 CRUD + 圖片上傳 | 5 |
| 第三單元為 CR | 1 |
| 第四單元為 CRUD + 圖片上傳 + 編輯器功能 | 8 |