PO或老闆：軟體甚麼時候能夠上線？甚麼時候可以給客戶用？

PO或老闆：軟體甚麼時候能夠上線？甚麼時候可以給客戶用？

1. 列出必要開發的功能(PBI)

2. 並依重要性排出優先順序(Priority)

3. 必要功能粒度相對大小評估(T-Shirt Size)：S, M, L, XL

4. 使用sprint0進行穿刺實驗(Spkie)：

(1) 從PBI中挑選S、M、L各一個項目放入sprint0，開始開發

(2) 開發過程中，紀錄S、M、L各需要多少Story Point(開發時間)

(因為是估算，其實精確在幾點幾分完成不是重點，真正耗費的總時數才重要，為了統計平均用)

(3) 推算一個sprint的產出速率 (每個sprint可以產出多少story point)

注意PBI 的 size 是否有大到超出 sprint 的範圍，也就是一個 sprint 做不完某一種 size 的 PBI 。若有此情況，則需考慮拆細 PBI 並調校 size 的定義。

5. 所有的PBI進行 story point加總

6. 初估團隊速率與專案完成時間

7. 每次sprint結束後，持續修正團隊速率與PBI size的估算，看看是否還是能夠如期完工。(Yesterday weather)

8. 重新檢視與評估需要的完成時間

(1) 按照目前速率，是否能如期完成所有功能

(2) 如果無法如期完成，有甚麼選項可以選：

        1) 延期 (團隊工作速率(工時)不變)：需要延多久

        2) 調整功能重要性順序，刪減較不重要的功能 (團隊工作速率(工時)不變)：刪哪些就可如期完成、只刪去A或B功能，要延期多久可以交付軟體

        3) 加班(增加工時)：每天要加班多久，才能如期完成

舉例：若S、L、M分別用了5、13、20 Hr，這三個PBI共用了1週的時間完成，則：

* 團隊的Velocity為(5 Hr + 13 Hr + 20 Hr) / 0.5sprint = 76 Hr / sprint

(通常一個完整的sprint為期兩週，所以1週就是0.5個sprint)

* S、L、M各 size 對應的 story point 基準為5 Hr、13 Hr、20 Hr

* 專案總共有S、M、L各2個PBI，完整的product backlog為76 Hr。目前已經完成S、M、L各一，剩下的 product backlog 大小為 38，只需要38 Hr / 76 Hr/sprint = 0.5 sprint就可以完成，也就是1週。

{Reference} 

Why are software development task estimations regularly off by a factor of 2-3?

[英文]

https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=kw

[中文]

http://www.inside.com.tw/2013/10/24/why-the-last-20-of-work-takes-the-same-amount-of-time-as-the-first-80

Why Software Development Estimations Are Regularly Off

https://diegobasch.com/why-software-development-estimations-are-regu

Scrum Estimation－Story Points and Planning Poker

https://dotblogs.com.tw/hatelove/2015/11/23/scrum-estimation-story-points-and-planning-poker

Scrum Estimation－如何估算專案時程

https://dotblogs.com.tw/hatelove/2015/12/19/scrum-project-schedule-estimation

Scrum Estimation－Dog Point Game

https://dotblogs.com.tw/hatelove/2015/12/01/scrum-estimation-dog-point-game