估算是Scrum和其他敏捷過程中的支持活動之一。這意味著評估故事大小的過程，即需要花多長時間，實施多少工作，花費多少，或者你想要它。在Scrum中，估算是團隊活動。對於每個故事，整個團隊參與估算過程。計劃撲克 （有時被稱為Scrum的撲克）是一個簡單但功能強大的工具，使團隊估計更快，更準確，更有趣。這個詞由James Grenning創造，由Mike Cohn推廣。
沒有計劃撲克的估算
這是團隊估算的典型問題。假設我們正在參加sprint計劃會議，產品負責人說：
OK guys, how long will this story take?
好吧，夥計們，這個故事要多長時間？
因此，團隊開始考慮故事需要多長時間（在這種情況下，理想的工作日）…
A先生認為他確切知道需要做什麼，所以他認為這需要3天。B和C夫人更悲觀。D先生和E先生正在懈怠。所以讓跟隨A先生說“3天”。
這使得B和C感到困惑。他們開始懷疑自己的估計。E先生醒來時並不知道估計的是什麼。D仍在打瞌睡。產品所有者要求團隊的其餘部分估算。
使用Planning Poker進行估算
現在想像一下，每個團隊成員都持有一副牌，包含以下牌：
讓我們重做估算。產品所有者說：
團隊再一次開始思考這個故事需要多長時間。
這一次沒有人脫口而出。相反，他們都必須出示一張卡，面朝下，包含他們的估計。每個人都必須出示一張卡片，所以D和E先生醒來。D先生承認他正在睡覺，並詢問故事的內容。以這種方式進行估算時更難以懈怠：o）當它們完成後，所有卡片都會同時翻轉，揭示每個人的估計。
哎呦！這裡有很大的分歧。團隊，特別是A先生和C夫人，需要討論這個故事，以及為什麼他們的估計是如此截然不同。經過一番討論，A先生意識到他已經忘記了一些需要包含在故事中的重要任務。C太太意識到，根據A先生提出的設計，故事可能小於20個。經過討論（總共3分鐘），他們對同一個故事做了另一輪評估。
收斂！好的，不完全收斂。但是他們同意估計5應該足夠接近。下一個故事。
為什麼奇怪的數字系列？
費氏數列有一個有趣的特性，每一個數字都是前兩個數字相加。另一方面來說，越大的數字與下一個數字的差距會更大。如上圖，8 與 13 的差距為 5 ，而 13 與 20 的差距為 7 。這跟估算需求復雜度有什麼關連呢？我們不是在上數學課啊。
估算也有個特性，就是越大的越估不准，把較大的需求或任務切到粒度較細時，往往估算起來就會比較精準。就像一個杯子中如果裝的都是大塊不規則的石頭，那麼中間的縫隙會比較多，這就是失准或浪費的部分。如果裝的是粒度較細，一樣不規則的石頭，縫隙相對會少一些，而且容易進行調整，能比較方便地填滿縫隙。
即使是前面的數字差距比較小，也沒有關係，因為本身數字小，代表挪動彈性大，風險低，如果因為某些因素時間估算失準需要調整，前面小數字的任務，大概就是加班20 分鐘，而不是加班2 天或5 天的情況。
因為大的數字差距較大（費氏數列兩個前後值的差異比率趨近於 1.618），所以能避免估算時發生「到底這個複雜度是 20 還是 21 」的情況。要嘛 13 ，要嘛 20 ，要嘛 40 。這樣的級距差距可以突顯出大家對同一個需求估算的差異，因為幾乎都差了1.5 倍以上，這比例對人類在判斷相對大小是相當容易的，也因此可以減少許多細微差異所引起不必要的重新估算流程成本。
因此數字越大，細微性越小。為什麼？所以，為什麼沒有21例如？幾個原因：
- 通過限制選擇的數量（即卡的數量）來加速估計過程。
- 避免高估計的錯誤準確性。
- 鼓勵團隊將大型故事分成小型故事。
高估計（例如> 20）通常意味著故事沒有被詳細了解。討論故事是19,20還是22.5是浪費時間的。這只是一個大故事，而20將反映出這一點。如果你想詳細介紹，可以把故事分成幾個小故事。可以更詳細地估計較小的故事。
特殊卡片
零卡意味著“這個故事已經完成”或“這個故事幾乎沒有，只需幾分鐘的工作”。
問號卡的意思是“我根本不知道。沒有。“應該是罕見的。如果過於頻繁地使用此卡，團隊需要更多地討論這些故事，並嘗試在團隊中實現更好的知識傳播。
無限大，則代表需求明確，但超過最大的那一張數字卡，代表這個需求需要再被細分成多個粒度較細的需求。
咖啡杯卡意味著“我太累了，無法思考。我們稍作休息吧。“
有各種方法來估計應用程序開發項目。一種方法是使用所謂的故事點。雖然這種類型的估算可能不是最簡單的，但使用Story Points進行估算可為應用開發者和客戶帶來好處。
通過幾個步驟，這裡是如何玩規劃撲克...
設置場景：一套規劃撲克牌包含4個顏色編碼的值集，用於評價用戶故事。每個開發人員都有一組（例如，紅色的）。在該組中的每個卡具有不同的值（通常為1，2，3，5，8，13，21，等等）與該顯影劑分數，或尺寸，用戶故事。
1- 產品所有者徹底，但簡要地向開發團隊解釋用戶故事。
2-開發團隊隨後會詢問任何必要的問題，以確保他們完全掌握將用戶故事從概念轉變為絕對完成所需的工作範圍（包括升級/測試/等）。
3-然後，團隊中的每個成員都會快速確定他們認為總結完成所需工作量的故事點數。
4-當所有成員都準備就緒時，他們將牌放在一起。這會同時顯示所有估算值。
5-此步驟可能有所不同。
6-（或7-）為所有用戶故事分配故事點。
第5步可能有所不同？
在完美的情況下，團隊中的每個成員都會估算出相同的值。如果他們這樣做，第5步是......
5-將該編號分配給用戶故事並轉到下一個。
但是世界通常很混亂，你的團隊可能會為一個用戶故事呈現不同的分數。這會創建一個關於復雜性的對話框，並說明每個團隊成員對潛在隱藏困難的洞察力或更有效的完成方法。在這種情況下，第5步是......
5-每個玩家都會捍衛他們的估計，每個人都重複步驟3和4，直到得到一致的分數。
接下來是：
6-為用戶故事分配一致的分數，然後繼續下一個。
就是這樣！
本練習的主要目標是確保每個團隊成員，尤其是那些產生可交付成果的團隊成員，完全理解用戶故事的完成途徑。當實現這種統一時，工作得更有效，項目估算更準確，更有可能滿足期望。
但在我讓你擺脫困境之前，讓我再給你一些東西......
這是一個有用的提示：
注意你花了多少時間玩規劃撲克。雖然你想要準確無誤，但你也想要快速做到這一點。你的時間很寶貴，所以不要用它來旋轉輪子，用它來取得進步。
這是一個可悲的事實：
雖然所有新任務都有固有的學習曲線，但如果你的團隊花費數小時來捍衛不一致的估計，你可能沒有一個超級凝聚力的團隊。（yikes。）這意味著你可能在團隊建設方面有一些工作要做，甚至你可能需要重新安排或加入新的開發人員。從好的方面來說，這個令人遺憾的事實意味著您還可以使用規劃撲克來確保您擁有一支穩固，團結，超級有效的團隊。
總而言之，規劃撲克聽起來像是形成估算的一種非常強大的方式，對吧？最後，Planning Poker比其他任何敏捷估算技術都做得更好：
- 它統一了你團隊的不同觀點
- 它設置了相關經驗支持的任務估算
- 它建立了可靠的工作速度
對於軟件開發人員，利益相關者以及其他任何掌握產品的人來說，規劃撲克的工作原理是因為它可以協調想法並平衡期望。這是非常寶貴的。
其他推薦嘅 scrum 文章
- What is Product Backlog in Scrum? Who Responsible for It?
- How to Refine Product Backlog?
- What is Sprint Backlog in Scrum?
- How to Prioritize Product Backlog Using MoSCoW Method
- How to Prioritize Product Backlog Using 100 Points Methods?
- What is a Sprint Goal in Scrum?
- What is Burndown Chart in Scrum?
- What is the Role-Feature-Reason Template?
- Sprint Increment vs Potential Shippable Product vs MVP vs MMP
- Write SMART Goals & INVEST for User Stories
- What is DEEP in Product Backlog?
- How to Write Product Vision for Scrum Project?
- How to Use Scrum Board for Agile Development?
- Who Create Product Backlog Items or User Stories in Scrum?
- What is Agile Estimation?
