Scrum第十三步：第二次Planning meeting

【Scrum第二次Planning meeting】
〈Scrum第一次Planning meeting〉前提摘要：採用Bottom up方式，以理解Scrum元素為主，先寫出Task再補上Story。

先來回憶一下指南說的：
Sprint Planning 回答以下問題：
 ● 這次 Sprint 可以發佈什麼樣的 Increment？ 
● 如何做才能夠達成 Increment？

有了上一次經驗，團隊成員應該都稍微熟悉有哪些流程與內容要做，這次SM可以大膽嘗試，只做開場說明，然後交由團隊寫出這次要Sprint任務。

這次大致目的：
。SM以第三人旁觀角色，觀察與紀錄整個過程，並事後回饋修正
。了解User Story為何，
。PO寫出User Story，讓Develop Team有依據寫出Task，
。驗收標準在Planning meeting中先不寫，可以在Review meeting前在找關係人討論寫上，
。順序、估計則視狀況，通常越熟悉整體流程與資訊越完整情況下，寫的意義會比較大，但也表示付出的Plan時間成本會更多。

大原則，比上一次(只寫出Task)再多一些了解(User Story與標準驗收)與進步(由User Story寫出Task)即可。

前置作業：
。先與PO討論、溝通流程(大致會進行的方式)與內容(預計輸入、輸出物)，
。請PO準備好這次要執行的User Story。
。印列User Story表格單
。列印Scrum指南中提到Planning meeting的部分資訊、別人的Planning meeting情境參考
。開場前可以花個5分鐘講解

實際過程：
。延續上次story map與系統情境流程圖繼續衝刺
。PO白板列出可能會有哪些關係利害人(提供思考)，
。PO白板標示出User Story的描述格式，"身為Role，我希望Goal/Desire，以便於Benefit/Value。"(提供思考)，
。PO依據"系統情境流程圖" 寫出User Story提供參考，
。Development Team與PO討論User Story，
。Development Team可以在理解後，另外嘗試寫自己的User Story或者直接依據PO的寫出Task，
。標準驗收(AC)則在Review前，與項目的負責相關人討論補上。

SM有時可以採取一些手段，來讓事情加快進展，不一定要像褓姆一般，一步步照顧引導得很好。做中學，事後馬上回饋，讓團隊可以在下一次修正，可以成長得更快。當然要先建立好安全的空間與範圍，要好好拿捏分寸。

身為SM第三人稱觀點，去仔細觀察、紀錄要好好運用。譬如說，成員有哪些卡卡不順(人員不知如何下手動筆)、有無特別冷場的情況、訊息只有單向而不是雙向溝通、對於User Story較難理解也無法轉換、寫出的TASK不夠具體或太大...等等。

引用「引導學」一文：場域設計的五大要素，目的、目標、規範、流程、成員。
可運用這五元素先思考這次活動在腦中模擬的情境，讓大腦有所依據後，面對實際流程的任何狀況，才能從容應對。

整個系統思考原則，"付出的時間成本與可執行衝刺任務的平衡"，只要成員知道接下來要做的事能滿足，其他則在過程中慢慢補上，讓團隊不斷的近程勝利感前進，而非挫折感停止。滿足點可以參照指南說的，
在 Sprint Planning 結束之際，Development Team 應該能夠解釋給 Product Owner 以及 Scrum Master，他們要如何自我組織來完成 Sprint 目標以及開發出預定的 Increment。 

有限的時間、資訊的Planning meeting，最常發生的實際情況，
。成員或看板反應出Task常常有缺漏，
。燃盡圖好像沒效益，
。永遠不準，產生不信任感，
。Feature好像哪裡怪怪的(從Map →Task似乎接不起來)

不外乎就是「問題」("期待"與"現實"之間的落差)，SM不要太害怕這落差，要察覺這落差的主要原因，採取相對應方法解決。

個人覺得如果還在容忍範圍內，不會導致專案無法進行，都可以在後續階段修正。
差別在於，團隊成員共識到專案還需要更多更精確的討論與規劃，到時再付出討論時間成本會更有效益。先用最小的滿足點，慢慢往上堆疊。

結論：
沒有一次到位的完美，只有不斷修正的漂亮。一件有質感的藝術品，也必須透過不斷修飾成形，慢慢雕塑最終成品。持續改善，找出屬於這團隊的方法與節奏。

User Story參考
使用者故事參考

上一步：Scrum第十二步：第一次Retrospective meeting
下一篇：Scrum遊戲化體驗-用戶故事地圖
下一步：Scrum第十四步：第一次Refinement meeting
Scrum過程總結