產品待辦清單（Product Backlog）是一切 Scrum 活動的起點，我們可以把它簡單理解成軟體需求清單的超集合，這個清單裡除了有功能性需求、非功能性需求外，還會包含技術團隊提出的需求（比如說架構調整、程式碼重構），而不只是一般意義上的「軟體需求」，為了不讓名詞產生混淆造成誤解，所以 Scrum 裡特別使用了 “Product Backlog”，產品待辦清單來區別於傳統意義上只描述客戶端所要的系統需求。
產品待辦清單是現階段已知需求的總合，主要由產品負責人負責。同時這個清單經過排序，排序的依據，端看這個專案的目標是什麼，通常會以商業價值的高低來作排序，而在 BX（Boss Experience）導向的專案中，則會以老闆們在意程度的高底作為排序依據。誒真的啦，認真表述沒在婊述，有些專案的重點跟商業價值無關，而是跟最高薪或出錢的人開不開心有關，也就是所謂的河馬角色（ HIPPO，Highest Paid Person's in Office），只要他們能夠滿足，就可以順利結束這回合，歡喜過年。
需要注意的是，由於迭代方法論的本質因素，Product Backlog 是會一直不斷變化的，在案子的生命週期裡，PO 會隨著商業條件的外在變化，利害關係人的意見潛變，進而增加、刪除、修整、重新排序產品待辦清單。你可能會覺得，這樣變來變去， RD 無所適從啊 (怒吼~)！ 別擔心，一但被 Scrum Master 與開發團隊在 Plan Meeting 裡放進 Sprint Backlog 裡的項目，Scrum Master 及 PO 會鎖定並保護住至少一個 Sprint 的週期，讓開發團隊得以安心開發，這點在此先不展開，之後的文章再回來說明。
產品待辦清單的表達方式很多種，在 Scrum 中常用的是使用者故事（User Story，簡稱 Story）。使用者故事會描述「對使用者有價值的功能」，語句結構長的像是這樣：
身為一個 ______ ，我想要 ______ ，是為了 ______
仔細觀察，這個語句其實在講三件事：使用者類型、需求功能、背後目的：
【使用者類型】身為一個 ______
【需求功能】我想要 ______
【背後目的】是為了 _______
例如開發健身 APP 時，想要做的訊息推送功能，其中一個 User Story 就可以寫成：
身為一個 運營，我想要 推訊息給太久沒使用的用戶，是為了 激活用戶回來運動
另一個例子，開發購物 APP 時，想要做快速多筆一起結帳的功能，可以描述成：
身為一個 買家，我想要 將不同商家的商品加入同一購物車 ，是為了 節省時間（多商品可以一起結帳）
註：User Story 除了在 Scrum 中用到，在設計領域其實也會用它描述設計需求，不過顆粒度相較 Scrum 裡會大上許多，有興趣的朋友請參考 Rson 去年的鐵人賽文章 <User Story 與 UX / UI 設計流程>
接下來這段是 Rson 自己實務上的一些做法，可能和書上或 “Hardcore” 的 Scrum 觀念有點出入，大家參考看看。
許多朋友可能會認為產品待辦清單裡就是一堆的使用者故事所組成，所以每個 Story 都要照著語句文法，寫的很詳細，其實不然，有時候仍可依需適時的作調整變形。像是若經常需要使用 Jira 看 Sprint 的需求，傳統 Story 的語句描述方式其實不利於 PO / Scrum Master 在 Jira 上「掃視」，快速掌握大的輪廓。
我自己的作法是會將 Story 的名稱做精簡，愈是關鍵字放愈前面，並且只表達 What。但 Story 的精神是不只要傳達 What（做什麼），還想能夠傳達 Who（什麼類型的用戶需要這個功能），以及 Why （What 只是手段/方法，更重要的是背後的目的為何）。為了方便掃視而在第一層就被精簡了的 Story ，實在很可惜，所幸 Jira 的每張卡中都能附加描述，我們就能將完整的語句陳述寫在描述中，讓工程師除了知道要開發什麼，也能知道這功能的使用者是誰、以及他們為何需要。
使用者故事的拆分方式及寫法，每個人的觀點、習慣都不一樣，業界的 Scrum 大師與前輩們留下了一些智慧經驗，稱做 INVEST 原則：
iThome鐵人賽
看影片追技術