迭代策劃會議（Sprint Planning） 的實際案例
某專案組第一次採用敏捷方法進行開發，確定了迭代週期為三週。該專案組投入的資源如下：
前端開發工程師一名；
後端開發工程師一名；
測試工程師一名；
PO一名；
SM一名；
前後端開發採用不同的技術，熟悉前端開發的工程師不熟悉後端的技術，後端開發的工程師也不熟悉前端使用的技術。
當第1周結束後，由於前端開發人員使用的是新技術，需要熟悉新技術，而後端工程師與測試工程師的投入都不到位，因此估算工作量與實際工作量差別比較大。諮詢顧問介入瞭解情況後，指出了本專案組在迭代策劃時的錯誤，並指導專案組對後續開發活動進行了如下調整：
1.將三週的開發週期調整為一週一個迭代的開發週期。在不熟悉敏捷開發方法時，迭代週期要短，要及時總結經驗教訓，進行自我學習。
2.鑑於前期的迭代策劃做得不好，需要重新進行迭代策劃。
3.鑑於團隊的成員不是全棧工程師，因此將按角色分別估計工作量。
4.測試人員需要儘早參與開發，而不是到第3次迭代才進行功能測試。
重新進行的迭代策劃過程如下：
1.專案組全員參與了迭代策劃會議。另外包括：
專案組外部的測試工程師兩名；
外部諮詢顧問作為主持人；
QA人員負責實時在電腦上按照更新後的模板記錄估算結果，並投影出來；
其他多名觀摩學習人員。
2.首先請PO講解了每個使用者故事，然後依次讓前端開發工程師、後端開發工程師講解開發要點，包括設計思路、需要處理的需求要點、是否有歷史的複用功能、前後臺的介面等；接著讓測試工程師講解測試要點、澄清需要測試的需求細節。
在此討論中：
PO調低了某些使用者故事的優先順序；
PO刪除了一個使用者故事；
PO澄清了某些模糊的使用者故事；
前後臺的工程師指出了可以複用的功能；
前後臺的工程師對某些需求的實現方式做了溝通；
測試人員貢獻了很多澄清需求的想法。迭代策劃會議的一個重要工作就是做需求的溝通，要求專案組的所有成員要對需求達成一致的理解。通過填寫開發要點、測試要點、促使專案組成員對需求的理解進行溝通、討論、確認。
3.前端開發工程師、後端開發工程師、測試工程師分別選擇了一個故事作為基準故事，設定故事點為1，然後估算剩餘使用者故事的點數，從斐波那契數列中選擇一個最接近的點數，猶豫不定時，選擇偏大的點數。在做此估算時，前端、後端開發工程師、測試工程師都是背對背地、獨立地進行估算。因為每個角色只有一個人，所以沒有采用策劃撲克的方法，並且充分信任每個工程師的估算結果。如果估算的結果不準確，則在第1個迭代結束後，再調整估算結果。
4.三個角色對於選中的基準故事，分別估計了自己的工作量，然後推算出其他故事的工作量，合計得到每個故事的總工作量以及每個角色的總工作量。
使用者故事 | 優先順序 | 前端實現要點 | 前端實現的相對規模 | 前端工作量 | 後端實現要點 | 後端實現的相對規模 | 後端工作量 | 測試要點 | 測試的相對規模 | 測試工作量 | 工作量小計 |
故事1 | 1 | …….. | 34 | 34 | …….. | 21 | 21 | …….. | 21 | 10.5 | 65.5 |
故事2 | 2 | 0 | 0 | 8 | 4 | 4 | |||||
故事3 | 3 | 13 | 13 | 13 | 13 | 13 | 6.5 | 32.5 | |||
故事4 | 4 | 13 | 13 | 13 | 13 | 5 | 2.5 | 28.5 | |||
故事5 | 4 | 1 | 1 | 0 | 2 | 1 | 2 | ||||
故事6 | 4 | 8 | 8 | 0 | 2 | 1 | 9 | ||||
故事7 | 5 | 0 | 0 | 5 | 2.5 | 2.5 | |||||
故事8 | 6 | 8 | 8 | 5 | 5 | 5 | 2.5 | 15.5 | |||
故事9 | 6 | 0 | 1 | 1 | 2 | 1 | 2 | ||||
故事10 | 6 | 3 | 3 | 3 | 3 | 3 | 1.5 | 7.5 | |||
故事11 | 7 | 1 | 1 | 3 | 3 | 1 | 0.5 | 4.5 | |||
合計 | 94 | 59 | 33.5 | 186.5 |
有些使用者故事可能沒有前端或後端開發的工作量，則以0表示。
5.讓PO對所有的使用者故事劃分優先順序。首先請PO挑出最重要的一個需求，然後再挑選剩餘故事中最重要的一個需求，如果不好區分優先順序，就定義兩個需求的優先順序同等重要。此時，其他團隊成員可以提出自己的意見，直至大家對優先順序劃分的結果達成一致。在劃分優先順序過程中：
PO主動刪除了一個可做可不做的使用者故事；
當對所有的故事劃分完優先順序、並重新按優先順序順序排列後，PO又再次做了權衡，微調了優先順序；
對於成員質疑的優先順序劃分，PO給出瞭解釋。
6.每次迭代週期設定為一週。列出每個工程師在未來兩週中每週可以投入到本專案的工作量（小時），表示開發能力。
第1周 | 第2周 | 合計 | |
前端開發工程師 | 24 | 24 | 48 |
後端開發工程師 | 22 | 22 | 44 |
測試工程師 | 6 | 24 | 30 |
52 | 70 | 122 |
7.根據每週可以提供的開發能力，平衡需要的總工作量與開發能力，如果不能滿足需求的總工作量，則裁剪優先順序最低的需求，否則就需要提升開發能力、增加人員。由於估算的總體故事的工作量為186.5人時，超出了實際的開發能力122個工時，因此SM和領導協商增加了一個迭代，並且由於前端開發的工作量估計與實際能力差別比較大，確定再增加一個前端開發工程師。
8.根據使用者故事的優先順序，挑選了第1周完成第1個故事。第1個故事比較大，但是無法再進行細拆分為更小的故事，並且已確定再增加一個前端開發工程師，以確保第1個故事能夠在1次迭代內完成，並將第1次迭代的週期確定為6天而不是5天。
9.在上次策劃會議中已經將使用者故事拆分為任務，因此本次估算沒有再進行任務的拆分。留待責任人自己進行細拆分。
本次迭代策劃會議共耗時1.5小時。第一次迭代策劃會議估算了12個使用者故事，合計估算為186.5工時；本次迭代策劃會議估算了11個使用者故事，總估算工時也是186.5個工時，但是刪除了一個估算為17個工時的故事。雖然結果差別不是很大，但是估算的過程是不同的，上次估算並沒有進行認真的需求溝通，而本次根據不同的角色分別對需求進行了充分地闡述，同時這是在能力平衡的基礎上做出的迭代計劃，專案組成員更有信心可以按照計劃實施！
本專案針對迭代策劃會議的敏捷實踐，打破了常規的方法，變通執行，反而帶來了更好地效果。這也意味著敏捷軟體開發是經驗型過程控制，只要符合敏捷的原則，可以根據專案組的實際情況進行變通。