計算 Team Member 的 Capacity: 目前就是一位工程師工作時數 80% ，所以一個禮拜沒有請假的的情況將會是 40小時 80% = 32小時。請一天假則是 32小時 * 80% = 25.6小時。
依次把 Product Backlog 的項次轉換成 Sprint Backlog，預估時間、同時討論實作方式。預估時間的方式在後面Q & A.
當 Product Backlog 的項次需要完成的時間累積到大約是 Team 這個 Sprint 的 Capacity，則開始分配工作，每位 Member 只認領一項 Task，除非做完或卡住，才會任領第二項 Task，一開始分配完所有 Task ，容易造成每個人只 Focus 在自己手上的工作，影響團戰能力。
Q. Planning Meeting 請假怎麼辦？
A. 沒關係，等請假的人回來之後接第一個 Task 就可以了。
Q. Product Backlog 是不是只能排入有關於使用者端(有感 task )，User Story 相關的 Work?
A. 一種情況是如果沒有這項無感 task ，之後的 User Story 無法順利進行，這種情況就必須要把這項 task 放在 Product Backlog 裡面，第二種情況是這項工作跟現有的 User Story 在短期上看不到相對關係，但是被認為是重要的 task ，這種情況通常比較質性，有賴量性的數字來讓前後端溝通，達成共識是否要把這項 task 放進 Product Backlog 裡面。
Q. 怎麼 estimate 時間？
A. 大家先在不受人和人影響的情況下，提出自己的時間 (目前的方式是覆蓋一張時間排，等大家都出牌後翻開比較) ，然後來詢問 outlier 原因。估最快的人為什麼你估那麼快，你認為要做哪些事情？ 最慢的人毅然。確定大家都發表了自己的想法後，重新來一次，直到大家提出的時間收斂。
小提醒：請預估接下來兩個禮拜可能會發生的一些特殊情況，或是很有可能會突發而來的需求，預先把時間空出來，避免突然而來的工作需求打亂了整個 Sprint 的安排。