規劃是非常重要的會議，應該算是Scrum中最重要活動(當然啦，這是我個人的意見)。執行不好的sprint規劃會議，將會毀掉整個Sprint。
重要嗎？是的。是 Scrum 中最重要的東西嗎? 不是！回顧會議更重要！因為運作良好的回顧會議，會幫助你修復有問題的事情。只要其他事情都到位(好的產品 backlog，很積極的產品負責人和團隊，等等)，Sprint 規劃會議可以只關心相當瑣碎的事情。 此外, 迭代不是敏捷的唯一方法 – 許多團隊用看板來取代。我甚至寫過一本有關於它的小書：” Kanban and Scrum: Making the Most of Both” 。 http://www.infoq.com/minibooks/kanban-scrum-minibook Sprint
規劃會議的目的，是要給團隊足夠的資訊，好讓他們能在之後幾個星期內，能不受干擾地工作，同時也是給產品負責人能對此有充分的信心。
好吧！你可能會說這樣還是相當模糊。其實，Sprint規劃會議會產生出一些有用的成果：
• Sprint的目標
• 團隊成員的名單(如果他們不是100%投入，則需要列出他們投入的程度)
• Sprint backlog (也就是在Sprint中所包含的故事列表)
• 事前訂好的展示時間
• 對於Scrum的每日會議，事前訂好舉行的時間和地點
為什麼產品負責人需要參加
有時候產品負責人不願意花數個小時，和團隊一起討論Sprint的規劃。“同事們，我已經列出我所想要的，我沒有時間一直呆在Sprint的規劃會議中”，這是相當嚴重的問題。
為什麼整個團隊和產品負責人都需要參加Sprint規劃會議，原因是因為每個故事包含三項變數，彼此之間都有高度的關連。
範圍(scope)和重要性(importance)是由產品負責人決定的，但是估算是由團隊決定的。在Sprint規劃會議期間，經由團隊和產品負責人面對面討論，這三個變數才能逐漸調整到理想的結果。
一般來說，會議一開始產品負責人會簡述，對於Sprint和重要的故事而言，他想要達成的目標是什麼。接著，從最重要的故事開始，團隊逐一討論和評估每個故事。在他們做這事情的時候，他們必須對範圍提出重要的問題：“刪除使用者這個故事，需不需要把所有使用者還沒處理處理完的交易也一並刪除？”有時候答案可能會讓團隊很吃驚，因此而讓他們調整他們的估算。
在某些狀況下，對某個故事的時間估算，可能不是產品負責人所期待的。這可能會讓他調整這個故事的重要性，或是改變故事的範圍，因此而導致一連串的重新估算，等等。
像這樣直接合作的形式是Scrum的基本，事實上也是敏捷軟體開發的基礎。
如果產品負責人堅持，他並沒有時間去參加Sprint規劃會議，那該怎麼辦？我通常會根據以下的順序，來嘗試其中一個策略：
• 嘗試幫助產品負責人了解到，為什麼他的直接參與是非常關鍵，希望能夠改變他的心意。
• 嘗試讓團隊中某個成員，志願在會議過程中，扮演產品負責人的代理人。然後告訴產品負責人：“因為你不能參與我們的會議，我們會讓Jeff在這裡當你的代理人。在會議中，他會被充分授權，去修改故事的優先順序和範圍。我會建議你和他在會議之前，儘可能讓你們的想法一致。如果你不喜歡Jeff當你的代理人，你可以換其他人，只要這個人可以全程參加我們的會議就可以。”
• 試著說服管理團隊指派一個新的產品負責人。
• 在產品負責人找到時間來參加會議之前，會先暫緩Sprint開始的時間。同時，拒絕承諾任何交付項目。讓團隊每天都可以做他們最想要做的事情。
這個章節寫得不錯！<給自己一些掌聲> 只有一件事情 – 我強烈建議把 backlog 精進會議(評估，故事的拆解，等等)，變成一個單獨的會議，所以 sprint 規劃會議可以更專注。在這兩個會議中，產品負責人的參與仍然是相當關鍵的。
全站熱搜
留言列表
