既然價值不好控制也不易評估，許多Product Owner便將眼光放在「進度控管」上面，畢竟產品的釋出進度也是Product Owner需要負責的部分。Product Owner 10 個裏面有9個或多或少都覺得開發團隊進度太慢。Product Owner經常公開或私下抱怨：
- 爲什麼這個sprint只拿那麼少量的user story？
- 每個sprint承諾的user story爲什麼總是做不完？
- 承諾的user story做不完爲什麼沒有「自願加班」把它做完？
爲什麼快不了？
「預估進度與實際進度不符」是軟體開發經常面對的問題。根據字面上的意思，「預估」原本就包含「猜測」與「誤差」的涵義，而「實際進度」總是要等做出來之後才曉得。所以「預估進度與實際進度不符」實屬正常現象，請安心服用。
但是，身爲Product Owner還是要爲產品的整體進度跟老闆或客戶交代，因此無法容忍實際進度跟「Product Owner腦袋中的進度」相差太大。
Scrum只是一面照妖鏡。Scrum跑的好，可以反映出個人、團隊與組織的現況。如果Product Owner覺得團隊進度太慢，應該與團隊一起探討關於進度認知落差的原因，例如：
- 不熟悉Scrum：剛開始接觸Scrum的團隊，前半年可能都還在熟悉Scrum與敏捷開發的思維與團隊合作模式，因此開發進度會比較慢。
- 團隊的真實進度就是如此：以前隱瞞現實狀況才讓進度看起來符合預期，例如：犧牲品質、功能沒有做完但卻宣稱已完成，反正有問題等QA測試再來除錯就好了。現在跑Scrum，透明性增加，只是反應出團隊的真實狀況而已。
- 需求的不確定性高：需求的不確定性高，或是Product Owner與開發團隊缺少問題領域的專業知識，導致邊開發邊釐清需求，以及增加重工（rework）的時間。
- 技術的不確定性高：開發過程採用太多新技術，因此團隊成員需要花很多時間去學習與熟悉這些技術。加上新技術通常不太穩定，學習資源也比較少，因此增加團隊的學習曲線。例如，採用新的JavaScript框架、新的程式語言、新的軟體架構、新開發環境或建構工具。
- 多工與中斷太多：除了開發工作，團隊經常被中斷處理其他產品或專案的維護或救火工作。這可能代表以前開發的品質太差，現在回過頭來「討債」。或是每個人負責的工作太多，多工切換導致浪費，雖然每個人看起來很忙，但真正花在工作上的時間反而很有限。
- 外部相依性高：開發的產品有很多外部相依性，例如需要與協力廠商配合，或是開發軟體相依於公司其他部門的韌體與硬體。無法有效管理外部相依性，因而影響到產品開發的進度。
- 開發環境與設備太爛：有些公司業務團隊就在開發團隊的隔壁，業務與客戶講話自然音量比較大，干擾了開發團隊的思緒。另外，開發設備太爛也會嚴重影響開發進度，例如開發電腦太慢、記憶體太小、沒有雙螢幕、鍵盤太難打、持續整合伺服器跑太慢、測試設備不足等，都會影響開發進度。
- 開發人員不適任：進度太慢當然也可能是開發人員本身的問題，可能能力不符合團隊的期望，而且一直無法有效提升自己的能力。或是有些團隊成員立志當米蟲，能撈就撈、能混就混。也有些人比較適合傳統瀑布式專案，一個口令一個動作，不習慣Scrum團隊的自組織模式，因此表現不佳。遇到這種情況，就不需要客氣，該換人時就需要換人。
(摘錄: teddy-chen Blog)
Agile & Scrum Basis
