團隊如何決定哪些故事要放到這個Sprint中？
我們這裡使用兩種技術：
1. 憑感覺
2. 團隊速度的計算
憑感覺來評估
• Scrum master：“嘿，大夥們，我們能在這次Sprint中完成故事A嗎？” (指向產品backlog中最重要的項目)
• Lisa：“嗯，當然可以，我們有三週，這只是微不足道的功能”
• Scrum master：“OK，如果我們加上故事B呢？” (指向第二重要的項目)
• Tom 和Lisa一起回答：“應該沒問題”
• Scrum master： “好的，那故事A、B、C 一起呢？”
• Sam (對產品負責人說)：“故事C需要包含一些複雜的錯誤處理嗎？”
• 產品負責人：“不，你現在可以先跳過它，只需要有一些基本的錯誤處理。”
• Sam：“那故事C應該沒有問題” • Scrum master：“好的，那我們加上故事D呢？”
• Lisa： “嗯…”
• Tom：“我想我們應該可以完成它”
• Scrum master：“90%的信心？或是50%？”
• Lisa & Tom：“大約90%” • Scrum master：“好的，D也包含在裡面，如果再加上E呢？”
• Sam：“或許吧” • Scrum master：“90%或50%？”
• Sam：“我認為差不多50%”
• Lisa：“我很懷疑”
• Scrum master：“好，那先不去管它。我們要做完A、B、C、和D。如果還有空的話，當然我們我們可以做完E。但是沒人認為它應該被算到這次裡面，所以我們會先把它排除在這次Sprint計畫外，大家覺得如何？”
• 所有人：“沒問題！
” 對於小的團隊或是短的Sprint來說，憑感覺的評估方式還運作的不錯。
利用團隊速度的計算來評估
這個技術包含兩個步驟：
1. 決定估算的速度
2. 在沒有超過估算的速度下，計算有多少故事你可以加入
速度是一種“已經完成的工作的總量”的衡量方式，這裡每個項目是根據原始估算來進行衡量的。
在下面的圖形中，左邊是一開始估算的速度，和右邊是Sprint最後實際的速度。每個長方形代表一個故事，裡面的數字代表這故事初始的估算。
注意，這裡實際的估算是根據初始估算為基礎的，在Sprint過程中，任何有關故事時間的更新都被忽略了。 我已經可以聽到你的抱怨了，“這怎麼會有用？速度的快或慢可能取決於一大堆的因素！愚笨的程式設計師、不正確的初步估算、範圍的改變、或是在Sprint期間無預警的干擾等等。”
我同意，這不是準確的數字。但是它仍然很有用，尤其是跟什麼都沒有比的話。它可以給你一些不容懷疑的事實：“不管原因為何，我們以為我們可以完成的，和真正我們做的完的，還是有些差別的。”
在Sprint中，對於幾乎快要完成的故事，那又該如何處理？為什麼我們不能因此加部分點數到我們的速度中？呵呵，這裡必須要強調Scrum的精神(事實上，這也是敏捷開發和精實生產(lean manufacturing) 所強調的)，那就是要全部做完，可以出貨，才算是真正做完。事情做一半，它的速度只能算是0 (也許還可能是負值) 。你可以參考Donald Reinertsen所寫的“Managing the Design Factory”，或是Poppendieck的書，便可以知道為什麼會這樣說。
所以，我們是透過什麼神秘的魔力來估算速度？
有一個非常簡單的方法去評估速度，那就是查看團隊的歷史資料。在過去幾個Sprint中，他們的速度是多少？然後再假設下一個Sprint的速度也差不多。
這個技術就是有名的昨日氣象(yesterday’s weather)。團隊若要使用這項技術，必須滿足兩個條件：團隊已經做過幾次Sprint(所以有些統計資料可以得到)。以及在下個Sprint中，用大致相同方式來開發(也就是相同的團隊大小，相同工作狀況等等)。當然啦，並不是每次都能如此。
另一個較複雜的方法，是去做簡單的資源計算(resource calculation)。假設我們規劃一個由四個人組成的團隊，要去進行一個為期三週的Sprint。其中Lisa將會請兩天假，Dave只能投入50%的時間，並且會休一天假。所以讓我們把這些加在一起…
…將會得到這個Sprint會有50個可用的人天。
警告：這部分我真的不喜歡。我真的想要把下面幾頁撕掉！但是，如果你很好奇的話，請繼續閱讀它，我後面會解釋為什麼。 那這是我們所估出來的速度嗎？不是的，我們估算的單位是故事點數，雖然是可差不多對應到“理想化的人天”。一個理想化的人天是指能工作有效率，不受打擾的一天。但是這種狀況太少見了。我們還需要進一步考慮一些事情，像是把沒有規劃到的工作進去，員工生病不能工作等等。
所以我們的估計的速度一定小於50，但是到底少多少呢？我們利用了“投入程度” (focus factor)來解決這個問題。
投入程度是指能投入多少精力的估算。投入程度低，表示團隊預計將有許多干擾，或預期自己的時間估算是樂觀的。
廢話一堆。一些神奇的數學公式。只要使用昨日氣象就好，忽略投入程度這個沒意義的東西吧。
想要決定一個合理的投入程度，最好的方法是去看看上一次Sprint的狀況 (或是前幾次 Sprints的平均值更好)。
把上次Sprint中，所有故事的初始估算的值的總和，就是真實速度的值。
假設上次Sprint中，由Tom、Lisa和Sam三個人所組成的團隊，在三個星期內工作了45個人天，一共完成18個故事點數。現在我們試圖要算出下一個Sprint的估算速度，為了更複雜一點，有一個新的同事Dave要加入這個Sprint。把假期和新成員一起加起來，我們在下一個Sprint會有50個人天。
所以根據上面的公式，下一個Sprint的估算速度是20個故事點數。這意味著這個團隊，在這次的Sprint中，所能做的故事點數總和不能超過20。
在這個狀況下，團隊可能選了前四個故事，加起來一共19個故事點數。或是選了前五個故事，加起來一共24個故事點數。假設他們選了四個故事，因為最靠近20。如果沒有保握，那就再選少一點。
因為這四個故事加起來一共19故事點數，所以最後他們所估算的速度就是19。
“昨日氣象”是一個方便使用的技術，但是需要一點常識。如果上一個Sprint，因為大部份的成員都生病了一周，是一個執行的很糟的Sprint。你可以安全的假設你應該不會這麼慘，所以你可以評估下次的Sprint會有較高的投入程度。如果團隊最近安裝了新的CI (持續整合)系統，你可能可以假設投入的程度會比較高。如果有新人加入這次Sprint，你需要考慮會因為要訓練他，因而減低投入程度。
只要狀況允許，你應該看看前幾個Sprint，算出平均值，這樣會得到更合理的估算。
但如果是全新的團隊，你沒有任何之前的統計數據，那該怎麼辦呢？你可以看一下其他有類似狀況的團隊，他們投入的狀況是怎樣。
如果你沒有其他團隊可以參考呢？那就隨便猜一下。好消息是你所猜的值，只用在第一次的Sprint。之後你就會有歷史資料可以分析，以用來不斷地分析和改進你的投入程度和估算的速度。 我自己對於新的團隊，所使用的“預設”投入程度是70%，因為大部分其他團隊都能達到相同的數值。
那我們用哪一個評估的技術呢？
上面我們提到好幾個技術–憑感覺、根據昨日氣象來做團隊速度的計算、以及根據人日和預估的投入程度來做團隊速度的計算。
所以我們到底用哪一個？
我們通常的是結合起來使用，這並不會花我們太多時間。
我們會檢查上個Sprint的投入程度和真實的速度。接著，我們會檢查我們這次Sprint中所有可用的資源，並估算投入程度。然後，我們會討論這兩次投入程度之間的差別，必要時作出適當的調整。
好的，這是這個痛苦部分的結尾。我從未使用投入程度，因為它很花時間，產生出誤以為很精準的感覺，並且迫使你用理想人天的方式來評估故事。此外，投入程度帶來一個假設：更多人 ＝ 更快的速度，有時候這是對的, 但有時候不是。如果我們增加一個新人到這個團隊，在第一個或第二個 sprint，這個速度通常會變慢，因為人們需要花時間帶這個新人。如果團隊太大(像是超過 10 個人) ，這個速度必定更慢。
此外，投入程度這個詞，意味著這個值小於 100％，團隊並沒有全心投入，這會給管理高層一個非常誤導的訊息。
所以忽略投入程度和人天這些東西吧。只藉由計算故事點數。或是如果你都沒作估算的話，那我們只計算完成的故事個數，看看你在上幾個 spint 能做多少。這樣可以大致抓出，這個 sprint 可以完成多少個故事。如果在這個 sprint 中，你有些已知的干擾（像是有兩個人要去上課），可以移除一些故事，直到你感覺可以為止。如果你沒有太多歷史資料，則大多時間需要靠你的直覺。
以這樣的方式去進行，你的 sprint 規劃會議會變得更短，更有效率，以及更有趣。並且，出乎意料地，你的計畫結果可能更加準確。
一旦我們根據上次的速度和投入程度，算出這次Sprint該包含哪些故事，接著我會用“憑感覺”的方法再做一次檢查。我會要求團隊忘記之前算出來的數字，只要想像一下，是否這些這東西在一次的Sprint中，會太大而咬不下去。如果感覺太多了，我們就移掉一兩個故事。反之亦然。
在這天結束以前，只要決定出哪些故事要在這個Sprint內完成，我們就算達成目標。投入的程度、可使用的資源、以及評估速度的方法，這些都是達成目標的手段。
全站熱搜
留言列表
