上次我們已經介紹過3355中的3個角色，今天來介紹下Scrum中的三個工件。
- Product Backlog （產品待辦列表PB）
- Sprint Backlog （迭代待辦列表SB）
- Product Increment（產品增量PI）
任何一個成功的產品都離不開好的需求，而一個項目要很好的運作，首先要做好需求的管理，那麼在Scrum裡，PO（Product Owner）是怎麼做需求管理的呢？
Product Backlog （產品待辦列表）
產品待辦列表是包含產品所需的所有功能及特性並且有序排列的列表，任何需求的變更都應該唯一體現在需求待辦列表上。PB是由PO維護的。
PB包括需求，技術任務，工程架構相關的功能。這個backlog 有以下幾個特點：
- 有價值的。這個列表裡的每一個條目item都是對用戶有價值的工作；
- 動態的。這個需求列表是動態變動的，市場、用戶是一直在變化的，此外來自團隊，來自管理層也時常會對產品進行反饋，PO接收到這些反饋和變化，會根據起價值將它們以合適的排序整理並更新維護到Product Backlog裡，確保這個產品列表始終是最合理，最有價值，最符合用戶期望的。
- DEEP
- Detailed appropriately(適當詳細的)：優先級越高的條目在PB中排在越前面，需求也就越清晰，越詳細（大概率這些需求會在更近的未來release中被實現），而對於優先級越低，排在越後面的需求條目則詳細程度越低，需求細節約粗糙模糊，甚至只有一句高度概括的話。
- Estimated（估算的）：這個產品列表是估算的，優先級越高的產品條目估算越準確精細，而優先級低的條目可能只有一個非常粗略，甚至拍腦袋的估算，比如體恤衫估算S, M, L, XL。估算往往會影響到該產品條目的優先級，因為PO要考慮一個產品需求的投入產出比，如果一個需求所需的成本過高，可能會導致其優先級降低。
- Emergent（湧現式的）：該特點和動態是相關聯的，因為這些需求反饋，創意都不是一次性產生的，而是在各方不斷的使用體驗過程中發現，湧現出來的。
- Prioritized（排序的）：PB不是一個雜亂無章的列表，而是經過PO的仔細斟酌進行優先級排序的有序列表，是force ranked的。
Sprint Backlog （迭代待辦列表）
Sprint Backlog是Scrum的三大工件之一。Sprint及迭代，在Scrum裡，Sprint是一定長度的固定時間盒。Sprint Backlog是為Sprint選擇Product Backlog中相應的條目組成的項目集，它是Product Backlog的子集，用於交付產品增量和實現Sprint的目標。
Sprint Backlog包含了開發團隊為實現Sprint目標所必須的所有工作，其中包括PB中的需求條目，也包括為了實現這些需求條目所要做的其他工作，比如搭建環境，準備設備等。
此外，Scrum鼓勵持續改進的學習文化，Sprint Backlog還可能包括在上一個Sprint的回顧中得出的改進建議和具體措施。
在實踐過程中，Sprint Backlog往往被製作成Daily的Scrum Board，每項SB中的工作都被透明的展示在這個班上，用於每天的daily standup。
需要強調的是Sprint Backlog是由開發團隊來維護的，因為團隊決定如何拆分任務，如何分派任務，並且決定如何實現Sprint目標的交付。
在實踐中過程中，很多時候團隊成員誤以為Sprint Backlog，Scrum Board是由Scrum Master來維護，其實不然，Scrum Master會負責為團隊創建條件並引導團隊如何使用相應的敏捷工具來執行相應的敏捷過程，但是最終實際負責的還是團隊自己。
Product Increment（產品增量PI）
產品增量是指在一個Sprint期間完成的所有Product Backlog條目與所有先前Sprint的增量的總和，且必須是完成的，該增量最終體現在可以工作的軟件上。
這裡要介紹一個概念：DOD（Definition of Done）- 完成的定義
每個人對“完成”的理解都是不同的，這就好比一千個人心中有一千個哈姆雷特。因此在Sprint planning之初，開發團隊就必須對DOD做出明確的定義，每個需求條目要達到什麼樣的具體要求才算完成，才能被PO接受為產品增量。
每個Sprint交付的增量，PO可以選擇發佈或者不發佈，或者幾個迭代後一起發佈。PO會根據各方因素確定產品的版本發佈計劃。
