衝刺計劃
Mitch Lacey 原著。擁有者是 Mitch Lacey & Associates, Inc 顧問公司，專精於採用及增強敏捷與 scrum。
2012 年 1 月。
Sprint 計劃不需要是富有挑戰性的。這通常很有趣，也是整個 Scrum 小組透過一起努力回答「我們可以承諾什麼項目？」建立革命情感的時刻。作者提供可讓 Sprint 計劃專注於目標和產生實際效果的範例和策略，並詳細說明小組規劃 Sprint 時會遇到的常見問題及其可能的解決方法。
套用至
Application Lifecycle Management; Team Foundation Server
本文內容：
簡介
預測與認可
Sprint 計劃是什麼？
我們該如何完成它？
常見問題
情節：小組無法承諾產品擁有者所要求的所有劇本。
情節：產品擁有者沒有準備就來開會。
情節：第 1 部超出時間框限。
案例：第 2 部超出時間框限。
情節：產品擁有者無法參與。
情節：小組沒有所需的驗收準則。
情節：產品擁有者不知道「完成」的意義。
情節：Scrum 主管或產品擁有者正在評估/影響小組的估計/工作。
結論
我們不計劃。我們使用 Scrum，因此直接執行。
我一直不斷聽到這點。人們會認為 Scrum 和 Agile 意味著沒有計劃、沒有評估、沒有會議，什麼都沒有！這幾乎是事實。我們在敏捷專案中規劃多種的層級: 每日規劃或每日開會、每周計劃 (Sprint或反覆項目、待處理項目)、發行計劃 (產品待處理項目) 等等。
讓我們將焦點放在規劃 Sprint。
預測與認可
在 2011 年夏天，Ken Schwaber 和 Jeff Sutherland 修訂其《Scrum 指南》。在其中，他們移除了一個 Scrum 所熟知已長久確立的行為，也就是小組對產品擁有者和客戶許下承諾的行為。承諾已由預測取代。他們表示小組可以預測其工作，但是無法履行。
當我了解其邏輯時，我會因為下列原因而更希望獲得承諾：
認可某個項目會將小組置於不同的思考模式，這不只是預測而已。如果小組會預測，就表示凡是不符合他們聲稱可以做到的事都是可接受的行為。小組可能會從其預測中學習，但最終評估變化會變少。我發現預測的小組比認可的小組需要花更多時間減少變化。
預測 (或估計) 適用於產品待處理項目。不過，當小組將劇本從產品待處理項目移至 Sprint 待處理項目並加以細分時，他們要加入另一等級的精細度、找出小細節並自問「我們可否認可這點？」。進行預測所冒的風險是，小組改口說「我們只需要預設。如果遺漏某些資料，沒問題，我們日後都可以估計出來」，因而後退到懶散的狀態。
然後以較輕的語調 (想像您是對著老婆、老公、夥伴) 說「我預測我們會在一起十年」，或是說「我將自己的一生託付給你」。是啊，這就天下太平了。
最後，Scrum 的重點就是常識。建議您承諾方法和預測方法兩個都嘗試。這就是學習，與您使用的字詞無關，因此，放聰明點，兩者都實驗看看，並且使用其中最適合您、您的小組和您的公司的一個。
Sprint 計劃是什麼？
我們會召開 Sprint 規劃會議，一起計劃小組在下一個 Sprin 將建置的目標，以及建置方式。雖然我們將此稱為 Sprint 計劃會議，這實際上是由兩個完全不同的部分組成。第 1 部分專注於對小組要求建置的項目，產品擁有者和小組會出席參與。第 2 部分著重於小組如何規劃建置所需的功能。雖然整個小組必須參加第 2 部分，但是產品擁有者可以選擇不出席。如果產品擁有者由於某種原因沒有出席第 2 部分，產品擁有者應隨時可回答問題。
在 Sprint 計劃會議的第 1 部分，產品擁有者有機會向小組說明所需的一組劇本。這是劇本意義部分的深入分析。產品擁有者會介紹劇本、顯示互動方式並展示整個介面。此外，還可以檢閱基礎結構或架構項目。目標是提供足夠的資訊給小組成員的集體領導，這樣可以開始瞭解如何建置功能。小組會提出各種問題，以便收集關於如何進行會議的問題，例如：
「這些劇本的驗收準則為何？」
「您認為我們使用的是何種資料來源？」
「在這個元件上，要如何呈現介面的外觀？」
在 Sprint 計劃會議的第 2 部分期間，小組會將注意力轉向建置 Sprint 待處理項目，這是一份劇本及要求在該 Sprint 期間完成之工作的清單。為了建置待處理項目，小組將產品擁有者所要求的每個劇本分解成工作層級，每個層級每小時進行一次估計。在第 2 部分結束以前，小組會決定在 Sprint 期間，哪些劇本可以認可完成。
同時，Sprint 規劃會議的兩個部份可能需要花上二到八小時不等。我使用的 Thumb 一般規則是每一個區段應該是每週 Sprint 花費一個小時。這表示，如果執行一週的 Sprint，會議總共需要兩小時的時間 (第 1 部分要 1 個小時及第 2 部分要 1 個小時)。另一方面，如果我進行四週的 Sprint，會議將需要總共八小時 (第 1 部分四個小時和第 2 部分四個小時)。
我們該如何完成它？
只要小組讓 Sprint 計劃會議認可完成劇本清單，小組就已經達到 Sprint 計劃的目的。不過，要讓小組的每位成員都很自在的做出承諾，還是需要一點預先規劃和疏導。
產品擁有者在 Sprint 計劃期間只有一個工作 : 參與能夠描述一組所需劇本的會議。小組的目標在於從產品擁有者的角度了解劇本，分享產品擁有者的視野。Scrum 主管應該確定小組提出足夠的問題，並且也獲得了所有結果資料，包括接受度準則、草圖和任何假設。Scrum 主管也應該讓產品擁有者知道，小組開始將問題細分為工作之後可能會有其他問題。雖然產品擁有者提供的劇本，其點數總計大致與小組的歷史速度相符，小組最後實際上還是會根據在 Sprint 計劃會議的第 1 部分和第 2 部分中獲悉的資訊，決定是否承擔指定之 Sprint 中的所有劇本。
在小組從產品擁有者取得所有資訊之後，必須將劇本分割成各項工作，並建立 Sprint 待處理項目，這個待處理項目會為特定 Sprint 擷取所有劇本、附註、驗收準則、工作和評估。雖然有許多方式，但我採用下列方法，這個方法運用小組成員的所有意見，並且讓所有人都能參與工作分解。
Scrum 主管或會議召集人宣讀完劇本後，就會問「大家都了解了嗎？」小組應該已了解，因為剛才花時間與產品擁有者討論過。如果小組有人不了解，請花一些時間重新審視劇本，詢問產品擁有者的任何必要的問題。
接下來，讓每位小組成員抓取自黏便箋。要求每個小組成員在自黏便箋上寫下單項工作，然後將其擲入表格中間。
- 當個別自黏便箋擲入表格中間時，投擲者就宣佈工作。因此，如果「更新預存程序」被寫入，它將被醒目的提出。這很重要，因為它會激發想法並讓其他人說：「對呀！我們需要更新資料來源。」屆時會有人在便利貼上寫著「更新資料來源」、要求這麼做，並且將這件事情排入行程中。這個腦力激盪活動真的可以清除所有相關聯的工作。此時請勿擔心會有重複。完成所有工作通常每個案例需要五到十分鐘。
當便利貼都出現在資料表時，便可以排序它們。將這些都放在牆上，退後並觀察，有好多的自黏便箋！可以從識別所有重複項目開始；將看似重複的便利貼重疊在一起。然後，尋找因為類似或因彼此相依而似乎一起進行的工作。例如，如果兩個自黏便箋有類似的關聯性，就放在一起但彼此錯開，如下圖所示：
.png "類似的自黏便箋 - 位移")
如果這兩個工作密切相關幾乎相等，就將它們幾乎完全重疊，如下所示：
.png "類似的自黏便箋 - 重疊")
小組可以排序自黏便箋，揀選工作清單，以視覺化方式檢視剩餘自黏便箋之間的關聯性。
排序工作時，就可以估計。我會使用規劃撲克牌 (Planning Poker) 技術進行工作預估，但有一項差異：卡片上的數字代表時數而不是點數。我這樣做，是因為人員通常會因為不必要的細節而拖延太多時間，特別是在大型工作上。他們的驚慌其來有自。通常，公司會利用預估打擊小組。「您說需要 8 小時，卻耗掉了 12 個小時。」有什麼問題？」或「你說要 8 小時，結果只花了 4 小時。您在填補您的估計值」。
在卡片協助保持本文點估計概括性的同樣方式下，使用卡片進行工作預估，允許小組自由提供一組要選擇的固定數字，但同時要強制其最終做出選擇。這也可以避免激烈爭論某項工作應估計在 6 小時、6.5 小時還是 7 小時。
無論最終評估為何，別忘了，估計是由小組完成的，只適用於提高小組的信心，並協助他們根據速度判斷能否達成產品擁有者所要求的工作。工作估計值並非度量，而且不應該以這種方式使用。絕對不要使用評估做為對付小組的武器。
現在工作已預估，小組必須判斷本身是否有容量承擔更多工作。若要這麼做，您需要知道小組的產能、小組在 Sprint 期間可用的總時數。如果您有一個完整專屬的小組，決定容量會很容易，但如果您的小組是由兼任多項專案的人員所組成，就會難以決定。要求所有的人寫下個人每天可在專案上工作的時數 (或每次 Sprint 的總時數)。將所有數字相加取得可供小組使用的總時數。假設小組容量的結果是 200 小時。如果劇本的工作總和估計會使用 30 小時，就要求小組「我們可以增加更多工作嗎？」在早期階段，答案顯然為「是」。
由於您還有可填入的容量，請移至下一個劇本，並重複步驟一到步驟五。
(如需如何使用 Team Foundation Server 完成此工作的詳細資訊，請參閱敏捷式計劃和反覆項目)。
在某些點上，回答這個問題會讓人很頭痛：「我們可以接受更多工作嗎？」這是因為您快要接近小組的容量。當您遵循此流程工作時，請考慮不要填滿 Sprint 的容量。如果將水裝滿到杯子邊緣，非常可能會溢出來。Sprint 也是如此。如果估計的時數會耗用所有可用時間，而後來又在 Sprint 中認出新的工作，事情就會爆滿。您必須保留緊急工作的空間。
考量 Sprint 認可時，考量過去的 Sprint 回溯資料會很有幫助。小組是否一向都需要引入更多工作？或許在 Sprint 計劃期間，小組可以承諾更多工作。小組是否一向都無法完成 Sprint 的所有工作？小組解決未完成 Sprint 的根本原因之前，可能需要對認可較保守。
要說出數字來回答問題「您的杯子要裝水到多麼滿」的一個方法就是考量計畫大小的成長。計劃大小成長會測量實際花費時數與初始估計比較的情況。例如，假設我們小組的容量有 200 個可用時數。小組認定根據預估值為 190 小時。Sprint 結束時，小組計算出劇本包含了相當於 240 個實際工時的工作，計畫大小因此擴增 20%。
發現這個差異情況的小組應該花費一些時間在追溯調查原因：
是否在執行期間找到太多未於規劃時識別出的工作？
小組是否會據其目前的技能組合低估工作？
小組是否高評其容量？
等等。
小組再決定能否認可劇本時，也應考慮下次 Sprint 規劃會議時的計劃成長規模。回到我們的範例，如果小組仍然估計 200 小時的容量，則小組應該從上面減掉 20% 以彌補根據歷史資料「預期的」計畫大小成長。也就是說，若至少要在這個 Sprint 中避免溢出，小組應該在到達 160 小時的大小時，宣告其容量已滿載。
考慮計畫大小的成長率是一種指定 Sprint 應填滿程度的數量表示方法。不過，請明白目標不是要完全符合容量。正確地說，這是要讓小組感到有信心承諾適當數量的劇本，這個數量會催促小組行動，但不會不勝負荷。計劃大成長只是假設其他因素保持相同，而大約判斷下一個 Sprint 應該會有多滿。
評估所有劇本或劇本用完所有時間後，請回頭找到產品擁有者，並將小組認可交付的 Sprint 待處理項目告訴產品擁有者。Sprint 立即開始，開始工作吧！
常見問題
在多年協助小組採行 Scrum 的顧問生涯中，我已見過許多阻礙 Sprint 計劃成功的相同問題。雖然 Sprint 計劃看起來很簡單，但是剛開始使用 Scrum 的小組通常會很掙扎。許多這類問題及其可能解決方案會在本節中詳細說明。
.gif "Hh765982.collapse_all(zh-tw,VS.110).gif")
情節：小組無法承諾產品擁有者所要求的所有劇本。
偶爾會發生這種情形，這是正常現象。只要小組可以支援認可本主題稍早之步驟四和五中的資料，應用程式就能滿足產品擁有者。建議您確認過度填補或大型工作不會造成認可失敗。Scrum 主管應該挑戰看似過於保守的保預估，確認它們是正確的。產品擁有者應該對有兩位數的估計值之工作提出問題。任何預估需要兩個工作天以上的工作都應該細分為較小的工作並重新評估。這適用於所有專案，但對於執行單週或雙週 Sprint 的小組特別困擾。
情節：產品擁有者沒有準備就來開會。
有一個 Scrum 價值觀就是尊重。沒有準備就參加會議是失禮的行為。那麼，如果產品擁有者並未給予小組成員想要的資訊，小組成員應該怎麼做?雖然其中一個方法是選擇延後會議直到產品擁有者準備好，這麼做只會鼓勵同樣的行為，請盡量避免。另一項選擇是取消 Sprint。雖然這是可行的，還是很勉強。
我發現最好的解決方法是雙重的。首先，產品待處理項目應該有在某種優先權順序，因此產品擁有者若沒有特定的一組劇本，小組和產品擁有者就可以依優先權順序討論劇本，直到他們認為已達或超過容量為止。接著小組可以照常決定會議第 2 部分中需要討論的確切任務。
在會議之後，Scrum 主管應著手進行了解產品擁有者尚未準備好的原因。如果問題在於缺少參與感，Scrum 主管可以灌輸產品擁有者與會時應準備好一組劇本的重要性。另一方面，如果問題是產品擁有者無法準備 (可能因為小組協助其整備)，Scrum 主管應該也要協助解決這些問題。
情節：第 1 部超出時間框限。
另一種價值觀成為焦點所在。如果會議的第 1 部分勿勿結束，這是抓不到重點的徵兆。有時候產品擁有者因為缺少準備、沒有適當的排定優先順序、或是嘗試解釋太多的劇本而顯得不專注。其他時候，抓不到重點的問題可能是因為小組在「什麼」的交談中陷入「如何」的細節而偏離正軌。
Scrum 主管應該堅持產品擁有者將所有無法充分說明的問題列成表格，並且要求小組不要在第 1 部分進行詳細討論，以保持進度。修正沒有重點的討論的簡單方法是使用碼錶或計時器。
案例：第 2 部超出時間框限。
同樣的，請對準焦點。如果您小組的話很多，要求紀律以限制討論，有時候是恢復會議秩序的必要作法。準備煮蛋計時器，將工作預估之間的交談時間保恃在一兩分鐘之內。目標是正確性，而非 100% 精確度。
其他時候，在第 2 部分期間抓不到重點，是 Sprint 執行期間欠缺產品待處理項目整備的徵兆。「整備」是一段時間，小組可以在此期間和產品擁有者一起審視未來劇本與工作，以加入劇本或增量來確定設計方向或處理架構問題。若不修飾一般產品待處理項目，Sprint 待處理項目規劃會變得十分龐雜和痛苦。
情節：產品擁有者無法參與。
如果產品擁有者無法出席會議，沒有任何原因且未指派代理人，就當做是產品擁有者未準備好來參加會議一樣。處理最上層項目，並且儘可能認可這些項目。您可能會忍不住想變更會議時間來配合產品擁有者的排程。不該做的事。將會議的時間做平移以符合多數人的需求。這不值得。
情節：小組沒有所需的驗收準則。
在第 1 部分期間，我總是建議小組詢問產品擁有者「這一項的驗收準則如何？」或「我們要怎麼做才能讓您接受工作？」。如果小組在第 2 部分判斷工作時遺漏這一點，小組就不知道如何讓劇本結案。如果小組必須根據在第 1 部分聽到資訊猜測，則小組冒著產品擁有者的風險，決定劇本在 Sprint 結束時未完成，從每個劇本的開始要求驗收準則。Scrum 主管會指導您的產品擁有者提供這項資料。
情節：產品擁有者不知道「完成」的意義。
正如小組需要驗收準則，產品擁有者同樣應該獲得小組對所謂「劇本已完成」的最新描述。這份完成清單應張貼在醒目之處、保持最新狀態，並且隨時可供產品擁有者使用。過時的完成清單會使計劃變得困難，因為對於完成項目的外觀沒有共通的理解。請確定會在所有 Sprint 檢閱或追溯性中一併更新完成清單。
情節：Scrum 主管或產品擁有者正在評估/影響小組的估計/工作。
歡迎產品擁有者參加會議的第 2 部分，不過第 2 部分的產品擁有者角色應該限制為釐清需求或提出特定問題。產品擁有者不應該干擾小組討論如何實作劇本，也不會對工作的評估有任何評論。產品擁有者需要信任小組，才能做這項工作。
如果產品擁有者的作法偏離這些方針， Scrum 主管應該指導產品擁有者扮演更適當的角色。如果產品擁有者拒絕接受較被動的角色，Scrum 主管有權力要求產品擁有者退出。
Sprint 計劃不需要是富有挑戰性的。這通常很有趣，也是整個 Scrum 小組透過一起努力回答「我們可以承諾什麼項目？」建立革命情感的時刻。請記住，如果您發現會議進行很久，或許是有根本原因的問題導致這種情況。如果您是 Scrum 主管，請確認產品擁有者和小組在整備產品待處理項目，以維持會議的討論重點。在會議前準備好劇本驗收準則，以協助產品擁有者準備就緒。最後，協助產品擁有者和小組將精神專注在手邊的工作，判斷他們可以在這個 Sprint 中承諾什麼項目。