Sprint計劃會議概要

Sprint計劃會議在每一Sprint的啟動階段進行。

在Sprint計劃會議的第一部分，産品所有者和Scrum開發團隊（在ScrumMaster的協助下）共同審評Product Backlog，泰倫Backlog中各項目的目标和背景，并提供Scrum開發團隊深入了解産品所有者想法的機會。

在會議的第二部分，Scrum開發團隊從Product Backlog中挑選項目并承諾在Sprint的末期完成任務，從Product Backlog的頂端開始（換而言之，從對産品所有者具有最高優先權的項目開始）并按清單順序以此工作。這是Scrum的重要實踐之一；開發團隊決定承諾完成工作量的多少，而不是由産品所有者安排工作量。這就使任務的傳遞更可靠；第一，因為開發團隊承諾工作量，而不是其他人代替其“承諾”工作量；第二，開發團隊自己決定所需要的工作量，而不是其他人決定工作量“應該”是多少。産品的所有者對于開發團隊承諾任務多少沒有控制權，隻指導開發團隊負責的項目是由Product Backlog中按順序從上至下進行的。

開發團隊可以從清單底層選擇項目提前完成，如果其對于整個開發具有意義（比如，提升和快速完成較低優先權的項目，作為完成較高優先權項目的一部分）。

Sprint計劃會議通常會持續幾個小時－開發團隊對于承諾完成的任務作出認真地抉擇，這些責任要求通過仔細地考慮以達到成功的目标。團隊将從估算每一成員擁有的完成Sprint相關工作的時間開始－換句話說，是團隊成員平均的工作時間減去他們花費在檢修bug和其他必要的維護工作，參加各工作日可以完成Sprint相關的工作。（圖1）

Sprint周期	2星期
Sprint中包含的工作天數	8天

團隊成員	Sprint周期中可利用的天數	每日可利用的時間	Sprint中總共可利用的時間
A	8天	4小時	32小時（8×4）
B	7天	7小時	49小時
C	6天	5小時	30小時

                                            圖1預測可利用時間

當可利用時間确定下來，開發團隊會從Product Backlog的頂端第一項開始工作，換句話說，從産品所有者的最高優先權項開始。團隊共同工作，将其配置設定為小塊任務，并記錄在Sprint Backlog中。當任務确定後，團隊成員可以資源承擔任務，在考慮任務間依賴關系和次序的情況下，給每一項任務估算時間，并保證每一個人的工作量合理。在此流程中将會和産品所有者有往複交流，闡明要點，核實交易，将較大型Backlog分割成小塊，并保證開發團隊真正全面了解開發的需求。開發團隊将按Product Backlog序列繼續計劃，直至消耗所有可利用時間。在會議的末期，開發團隊将提供所有任務的清單，并寫明每一項工作由誰完成和他們的估計時間（一般以小時計算或每天的一小部分）。許多開發團隊也使用可視任務跟蹤工具，利用牆體面積大小的任務闆，任務(寫在便簽紙上)在Sprint中跨越欄目，“未開始”，“在進行”，“需校驗”，和“已完成”。

Scrum的重要支柱之一是當Scrum開發團隊确認承諾任務後，産品所有者在此Sprint期間不可以添加新的需求。這就意味着即是在Sprint中途，産品所有者想要添加新要求，他在下一新的Sprint開始前不可能作出任何變更的決定。如果一個外部情況出現緻使項目優先級的變化，意味着如果開發團隊按原計劃工作将會是浪費時間，産品所有者此時可以結束該Sprint，意味着開發團隊停止一切工作，重新開始Sprint計劃會議等等。此種決定會産生很大的影響，除非在非常特别情況下，否則不會采用這種方式。

保證開發團隊在Sprint中目标不被變換有着正面影響。首先，開發團隊确信在工作開始時的承諾是不會變化，這樣會集中開發團隊的注意力。第二，這樣也可以培養産品所有者在安排Product Backlog中項目的優先權時，适時作出正确的抉擇。他們知道任務的承諾是在整個Sprint中不可變更的，使其在決定從哪一個項目開始工作更為細心。

作為回報，産品所有者也可以得到兩個好處。首先，有充分的信心，開發團隊對所承諾任務強烈負責，并随着時間推移，Scrum開發團隊将會做的很好。其次，産品所有者可以在下一Sprint開始前，提出希望Product Backlog的項目變動。在這一點上，增加條件，删減條件，更改條件和重新排列優先權都可以被接受。但産品所有者不可以在Sprint進行中提出任何變更，職能等待下一個Sprint。