【Scrum規劃會議】(一)如何把工作目標說清楚
重新定義Scrum裡的Story，從說一個好目標開始！
為什麼要寫這篇文章?好的Scrum規劃會議，能讓大家有一致的目標，使團隊知道在接下來的衝刺期間，自己在做什麼、為何而做；不好的規劃會議，開完會的隔天，沒人知道要幹嘛，接著開更多會。規劃會議的好壞差距就是如此大，本系列會說明規劃會議關注的重點，並介紹實務可行的執行流程，將有助於你提升規劃會議的品質。
讀完這篇文章後，你可以獲得什麼?1.知道規劃會議需要完成的事
2.知道規劃會議可以如何進行
3.知道目標、故事的描述，將如何影響團隊的行動
Sprint Planning 規劃會議的用意 ?
規劃會議，是在精煉會議後、每日立會前的Scrum會議，為了讓所有人知道接下來的衝刺期（Sprint）會做什麼事。
在規劃會議開始以前，產品負責人（Product Owner）需要對產品的未來有方向感，方向感的體現包含了產品待辦清單（Product Backlog）的內容、順序，內容包含了產品接下來要改進、創造的具體項目。因此
規劃會議（Sprint Planning）可說是
為了讓產品待辦清單中的項目有效率地實踐，所進行的一場會議。
在歷時最多8小時的規劃會議中，我們要在會議結束後瞭解到這次的衝刺期（Sprint）
- 將帶來什麼樣的價值
- 將完成哪些產品待辦清單（Product Backlog）的項目
- 將會如何協作完成
會議結束後，會有一種快速看完一部電影的感覺，你會知道衝刺期的開頭、過程、結局。也就是每一個項目會如何被開啟，團隊如何配合與溝通，並知道最後的成果長怎樣。
接下來，我們會介紹可以如何進行這場會議，當然，如果團隊有喜歡的方式也很棒，只要能達成規劃會議的目標即可！
精煉會議：PO事前想好需要哪些Story
每日立會：每天掌握進度、調整手邊的事務
溝通目標，增強價值與方向的共識
Scrum規劃會議的開頭，可由Scrum Master 或產品負責人開場，說明會議的流程，強調這場會議的意涵。
接著，產品負責人花約 20 分鐘與團隊溝通衝刺目標（Sprint Goal）、長期目標，或甚至整個產品的目標（Product Goal）
如果可以，盡量在1小時內，團隊就要能足夠理解衝刺目標（Sprint Goal）的方向性，並對目標有一個結構性的概念，好讓後面有足夠的時間選擇、安排待辦事項。
能用什麼方式描述短、中、長期目標？
目標的本質，都在代指方向性，用相對簡單的方式，替複雜的內容下一個總結。它的作用是讓你在混亂的環境中，能有一盞明燈指引前進，有點像戰場上的軍人，如果能一開始就握有羅盤、一個總體的戰略方向，即便過程中受傷、改變行進路線、碰到障礙，都能擁有自己的判斷，並在分頭行動中仍往同樣的方向前進。
同樣地，工作中的管理者實在很難顧慮所有細節，也不可能監督每個人在做什麼。目標之所以重要，就是為了更多人擁有足夠的判斷力，在沒有上層管理人時，仍有一個良好的決策品質。
因此，只要是能幫執行者抓住重點、有助於長期發展的目標描述，都是一個好的目標。
而Scrum規劃會議，就是為了銜接長期的目標、短期的行動而存在的。
長期目標－產品目標（Product Goal）
長期目標，可以是產品目標（Product Goal），也可以由多個衝刺目標（Sprint Goal）組成，它幫釐清這次衝刺期完成後，對更遠的未來的影響性。
可以包含具體的數字（網站流量提高 30%）；亦或是敘事性的（成為市場的領導者、成為最便利的服務網站），為了達到這些目標，可能需要 3 次甚至更多的衝刺期才能達到。
中期目標－衝刺目標（Sprint Goal）
中期目標，是屬於本次衝刺的目標，確保團隊能在衝刺期結束後，能更清楚地檢視階段性的成果。
比較特別的是，衝刺目標並不是由產品負責人或開發團隊單方面決議的，它需要包含執行面、利害關係人（stakeholders）的考量，因此，會在Scrum規劃會議的過程中逐漸成形的。
你可以把它視為一個對於短期目標的綜合性總結。
例如：
這次衝刺打算做 3 個產品新功能：
購物車、雲端發票與刷卡、數據化報表
總結來說，本次的衝刺目標就是：
「完成方便易用的結帳系統」。
當然，隨著新功能類型越多、方向性越不一致，越可能難有一個總結，面對這樣的情況，第一步，請優先思考團隊是否足夠聚焦（Focus），如果判斷這些項目都是必須完成的，那也可以僅針對最重要的部分來設定目標，而不必做到一體適用。
短期目標－User Story / What can be Done
短期目標，是本次衝刺會完成的項目（item），也是從產品待辦清單（Product Backlog）中被Scrum團隊決定、計畫在衝刺期（Sprint）完成的項目。
當它們被選定後，就會被放入Scrum的衝刺待辦清單（Sprint Backlog）中。你可以把每一個項目（item）視為一個個的小型專案、工作包，但無論如何，它最好都是有一個固定範圍性的。
描述項目（item）的方式很多，你可單純用產品功能描述：
「設備找場地的網站」
「購物車功能」
「我的最愛清單」
也可以用User Story的形式，來讓短期目標能更容易被理解、具體、可檢測：
身為一個活動人員，我希望更快找到活動場地，所以我要一個「設備找場地的網站」
身為一個活動主辦老手，我希望更簡單地租借場地，所以我需要「我的最愛清單」
除了短﹑中﹑長期的目標，也可以用OKR階層式架構來建立目標
詳情參考 → 【OKR 實戰手冊】(一)如何有脈絡地把目標管理好？清楚為什麼，比很多事情都重要
說明這三種目標，為了讓所有的工作者「清楚為什麼要做。」
如果我們只說短期目標，是為了解決顧客的某個難題，有可能會讓人覺得團隊是為了改善產品品質，而忽略了中期而言，是為了要有更多的曝光。
反過來說，即便品質沒改善，但突然有機會能獲得大量曝光，那產品品質可能就暫時不重要了。
但如果有一併說明長期目標，那我中間如果突然有一個合作廠商願意幫忙曝光產品，那大家就會很直覺地放下手邊的事，好好地抓住著個機會。
實際Run Scrum或做任何工作時，管理者實在很難顧慮所有細節，也不可能監督每個人在做什麼。目標之所以重要，就是為了讓團隊在沒有管理人判斷的時候，仍能有一個良好的決策能力。
目前為止，我們瞭解到規劃會議的目標，也知道了可以如何描繪短、中、長期的目標，但仍有不少細節可以討論。例如：
- 短期目標的 User Story 是什麼 ? 怎麼評估目標設定的好壞 ?
- 如何確定會完成的項目 ?
- 如何衡量工作量? 如何規劃協作？
這些內容，將在後續的文章中陸續跟大家聊到！
如果你喜歡我的文章，請幫我拍拍手~「1下」拍手：到此一遊，留個記錄吧。
「5下」拍手：表示喜歡這篇文章。
「15下」拍手：表示你想要知道更多相關的內容！
「30下」拍手：手應該會有點痛，但還是歡迎繼續拍。按下「Follow」，追蹤我或我的專欄，將能定期收到優質的文章！
