如果 PO（產品負責人）不管三七二十一，先依據產品專案的大目標，制定出各個衝刺的目標，然後「要求」Scrum Master 和開發團隊（Development Team）一定要「使命必達」，您猜結果會怎樣？（呃…好熟悉的場景…）
可以想見，像「PO 搞不清楚狀況啦！」、「怎麼可能！」「叫 PO 他/她自己來做！」等等的抱怨聲浪和負面的情緒將蜂擁而至！
您覺得這很可笑，怎麼可能會有人這樣幹？可是，既然我們大家都知道這個簡單的道理、也必然會是這樣的結果，那為什麼，還是有很多的組織，卻仍一直在犯這種不當的管理方式呢？
PO 雖然是產品的總負責人，需要負產品成敗的最終責任，但是通常她/他不是研發人員背景出身，對於各個用戶故事，實際上到底會需要花費多少的心力（efforts）去實做和測試，其實是不太有辦法判斷得夠精確的。既然如此，那麼，PO 片面制定的各個衝刺目標，鐵定與開發團隊的看法有南轅北轍的差異，最後就會變成是 PO 自己訂爽的，做不做得到，又是另外一回事了！
那 PO 該如何顧好各個衝刺目標的制定主控權，又能讓這些目標制定得夠務實可行呢？
讓我們再度回到 Scrum 的設計初衷來想一下。Scrum 的設計初衷是「對內要創造高度凝聚力的合作團隊，對外要從客戶/用戶端取得即時的回饋」。因此，要創造高度凝聚力的合作團隊，PO 就必須要與 Scrum Master 以及開發團隊「一起」制定各個衝刺目標才對！
相信大家對目標制定的 S.M.A.R.T. 五原則應該都很熟悉了，其中的 A，就是要讓團隊能夠「做得到（Attainable）」。而要符合這個原則，首先就必須要先知道，這專案當中的每個用戶故事，到底會花費開發團隊多少的心力，才能夠實做得出來，測試完整，交給客戶/用戶去使用。
所以，PO 的首要之務，就是讓開發團隊先把高優先級的用戶故事，都精算細估出所需要的時間，對於相對低優先級的用戶故事，就先概略估算出其所需的時間即可！這樣一來，所有的用戶故事都有了它相對應的實做時間之後，PO 就可以很清楚地知道，每個固定時間週期的衝刺，到底能夠完成哪些用戶故事、提供客戶/用戶哪些功能、產生哪些價值，這樣才能夠制定出暨合理又能執行的各個衝刺目標，這樣不是很完美嗎？
別傻了，事情哪有可能這麼簡單！
依據上述的原則來做衝刺目標的規劃，第一個會遭遇到的問題就是，這些衝刺大多數都無法被最佳化地填滿用戶故事！那麼，我們又該如何補償和解決這個衍生性的問題呢？
待續．．．
相關文章：