前言
您可能多少聽過 Scrum 活動之一的規劃會議(Planning Meeting)，甚至已經參與在其中，但您可能還有一些困惑，例如：
- 為什麼要有 Planning meeting？
- 為什麼要定義衝刺目標 (Sprint Goal)？
- 為什麼團隊要承諾預計實現的項目 (如哪些 PBIs、哪些故事)？承諾的項目無法如期完成，怎麼辨？
在我的看法，這正是為了讓 Scrum 三大柱能正常發揮－－透明(Transparency)、檢視(Inspection) 與調適 (Adaptation)。
衝刺目標
設立目標在某些程度上是管用的，特別在多人協同當中，有共同的目標可以對齊，會是大家樂見的。在此不細談目標管理，但我們可以從中推導，一個好的目標，至少會有幾個特徵：
- 有價值
- 合理性
- 方向
- 時間
- …
在 Scrum 當中把「時間」劃上了一個淺淺的線－－衝刺的結束日期。為什麼說是淺淺的？因為它最多是一條參考線、一個低標準，若我們可以更早完成，並且更早取得回饋，才是更重要的，盡量避免讓大多數的工作集中到最後一天完成。而「有價值」與「合理性」會體現在每一個 PBI 當中，團隊透過討論不斷提升，或是淘汰尚無價值，或尚未合理的項目。
那麼「方向」呢？
在 Scrum Guide 提到，一個 Planning 之所以有價值，是因為全團隊一定義 Sprint Goal，這個 Goal 表達了「為什麼本次衝刺(對於利害關係人)是有價值的？」。這聽上來還是有些拗口，但重點仍在「有價值」，做什麼東西有價值？
目標與承諾
我們可以從 Scrum 的設計上看出它想要團隊發揮自主的潛力，也增加了許多溝通、檢驗、及早回饋的環節，這是相當可貴的，特別對於一些執行隕石驅動開發團隊來說，能夠由團隊討論、團隊決定、團隊自主形成共識等，都是 Scrum 與敏捷方法想要帶來的好處。
承諾在規劃會議當中的體驗，大致有二：
- Sprint Goal 是什麼
- 要做哪些 PBIs
PBIs 將支持 Goal 的實現，回答「現階段該做什麼才是有價值的？」的問題，有助團隊找出哪些 PBIs 是該考慮執行的、哪些 PBIs 是可以被替換的、哪些要先做，哪些後做、如何應對突發狀況，好讓 Goal 能夠完成？
少了承諾，容易讓協作產生困難。例如 PO 並不清楚本次衝刺之後應該會有哪些東西被完成，這將影響到未來 PBIs 的規劃，相當考驗 PO 多重計劃的準備。開發人員之間也可能產生實作上的疑慮，例如難以拿捏目前的實作要做得多深？下多少功夫？是不是其他的 PBIs 有助於我目前的實作？先做什麼，會有助於下一個 PBI 的實作？但下一個 PBI 會做嗎？我現在做這個，萬一另一個 PBI 沒做，我該…？
衝刺失敗
還有一個大哉問是，東西沒做完是不是衝刺失敗了？這是個很有趣的問題，簡單來說，不是。
在《Clean Agile 無瑕的程式碼敏捷篇》一書當中提到：迭代不會失敗，它獲得了資料。資料可以幫助團隊調節，好找到更好的做法。例如沒做完可能因為團隊量能需要提升、需求發生不可避免的變動、大環境/基礎設施的影響…，於是團隊如何提升量能？如何增進技能？如何有效回應變化？如何讓基礎設施更為穩健，都可以是接下來的努力方向。
也許你會有個疑問「既然沒做完不是失敗，那是不是承諾就不重要？反正做不完就往後延？」。嗯… 試著打開二元分別的限制，多看到一些可能性，讓我們不同的方向來思考看看：
- 做不完往後延，這是 Scrum 通人性的地方。人可能會有各種的問題，環境亦是，世界不變的真理就是「變」，保證所有的東西都能夠完成反而是不現實的理想，這就是為什麼我們要有排序過的 PBIs，使有價值的東西先做，那些可能來不及完成的項目則能比較安然地移動到下一次的衝刺。
- 承諾有助協作，是團隊對齊的標的。團隊可以發現目前的工作負載，是否可以在預計的時間完成，這通常會借助燃盡圖(Burndown chart)來幫助看出端倪，這也是三大柱的發揮時機，透明、檢視、調適都基於有個明確標的存在。承諾也是一種激勵、一種提醒，少了可被督促的標的，許多你想做的事情很可能就這麼飄了過去。對於跨團隊(部門)而言，承諾也有助於溝通。例如部門之間可以大致了解，什麼時間點大概會有什麼東西被產出。
還有一種比較有邏輯的說法：衝刺成敗取決於 Sprint Goal 實現與否。這也是容易理解的，必竟 Sprint Goal 就是那最有價值、最重要、最關鍵、最需要實現的，不然團隊也不會(也不該)把它設為目標，因此觀念仍然是相通的，確保有價值的項目被完成，順應時運調適。
後記
相關的概念體現在 Scrum 的方方面面，都是在讓透明、檢視、調適能夠好好地發揮，若您對於其他的 Scrum 活動有類似的疑問，不妨往這些方向思考。同時，Scrum 在各活動設計上，以及各種最佳實踐都有它的理由，這也是為什麼初期導入 Scrum 通常會建議先「守」，而不是立即為團隊進行客製化，任意的摘除活動、做法、工具都可能損失一些原本想實現的效益。
