Scrum：誰負責創建產品待辦事項或使用者故事？

這個問題比表面上看起來更為複雜。首先，你可以說產品待辦事項待辦事項可以包含使用案例、大型功能、使用者故事，甚至錯誤，或是產品待辦事項內的時限研究任務。

在最簡單的定義中，ScrumScrum 產品待辦事項僅是專案中需要完成的所有產品待辦事項（PBIs）的清單。它取代了傳統的需求規格文件。PBIs 反映了客戶或利益相關者的需要。一種常見的捕捉終端使用者需求的方法是將 PBIs 以使用者故事.

誰負責維護產品待辦事項？

負責產品負責人（PO）代表利益相關者擁有產品待辦事項，並主要負責其建立。產品負責人無需親自建立待辦事項——他或她可以委派給開發團隊和／或Scrum 主管協助定義和估算待辦事項。產品負責人負責產品待辦事項的建立與維護。因此，產品負責人也監督待辦事項精煉流程。

產品待辦事項對應於你的專案路線圖——團隊計劃交付的計畫。團隊定義後，會優先處理要建構的功能與需求。產品待辦事項也作為一個儲存庫，包含團隊需要追蹤與分享的所有資訊。

產品待辦事項是否等同於使用者故事？

如前所述，PBIs 反映了客戶或利益相關者的需要。一種常見的捕捉終端使用者需求的方法是將 PBIs 以使用者故事的形式撰寫。然而，PBIs 也可以包含使用案例、大型功能、使用者故事、錯誤，或產品待辦事項內的時限研究任務。實際上，產品待辦事項中的所有項目並非都具有相同的細節層級，如下圖所示：

詳細的產品待辦事項

我們計劃近期處理的 PBIs 應位於待辦事項的上方，規模較小，且極為詳細，以便能在短時間內進行處理衝刺我們暫時不會處理的 PBIs 應該放在待辦事項清單的底部——規模較大，細節較少。這沒問題；我們並沒有計劃在近期處理這些項目。

當我們越來越接近處理較大的 PBIs（例如大型功能）時，我們會將它們分解為一系列較小且適合衝刺的敘事。這應該及時完成。如果過早細化，我們可能會浪費時間去研究那些最終不會被實現的細節。如果拖延太久，則會阻礙 PBIs 流入衝刺，進而拖慢團隊進度。我們需要在恰當的時機找到恰當的平衡。

敏捷優先排序的產品待辦事項清單

誰負責細化 PBIs？

產品負責人（PO）代表利益相關者「擁有」產品待辦事項清單，主要負責建立和維護它。PO 不需要親自創建每個待辦事項——他或她可以讓開發團隊和/或 Scrum 主管參與，協助定義和估算事項。PO 負責監督整個待辦事項細化流程。

因此，回答這個問題：產品負責人擁有產品待辦事項清單，但不需要創建每個待辦事項。通常，產品負責人可能根據高階需求或使用者目標創建大型 PBIs，然後委派團隊協助將這些大型項目分解為使用者故事。這些較小的故事——適合放在待辦事項清單的頂端，並符合「「就緒」（通常在「就緒定義」之下）——隨後被移入「衝刺待辦事項清單.