雞蛋估算法原理
雞蛋估算法，或者稱雞蛋計數法，在包括軟件開發的智慧工作領域，是指對所處理對象進行簡單分解後計量個數，直接作爲規模。比如在敏捷軟件開發中，對於迭代工作的範圍大小，直接以用戶故事個數爲規模，不再細分故事點數，不再識別子任務，也不再估算理想工時數量。
之所以用雞蛋估算法（也稱雞蛋計數法）來命名這個方法，是因爲雞蛋的大小範圍在同一個數量級上，容忍在這個範圍變化，不再做更精細的估算。
其實T恤尺寸法也有相同比喻的味道，一般而言，XS，S，M到XL和XXL，價錢都是一樣的。不過T恤尺寸法已經被廣泛使用成另外一種情形，在這裏提及，只是試圖說明雞蛋估算法在早些時候已經有苗頭。在有些場合，甚至直接計量需求個數，或者Feature個數作爲規模，不再細數需求裏面有多少個故事。
雞蛋估算法的原理，與NoEstimates的原理是大體相似的。從比喻的角度講，雞蛋估算法更加容易理解，而NoEstimates在字面表述上顯得激進，而且實質上是有估算的。
雞蛋估算法操作要點
這個方法的前提條件是如何控制“雞蛋”的大小。雞蛋和恐龍蛋如果放在一起，那麼恐龍蛋就會帶來失真的計量，需要把恐龍蛋分解到雞蛋，才能讓雞蛋計數反映真實的規模。
在具體操作上，對於故事，筆者推薦，雞蛋故事的範圍對等於原來故事點5以內包括5的故事，對於少數可能爲故事點8的故事，也可容忍爲雞蛋故事，但不能容忍原來大概是13點的故事。對於感覺到大概大於8點的故事，爲了按雞蛋估算法處理，就需要進行拆分。這樣，產品經理或者產品負責人或者BA等，就在源頭上就能瞭解待辦事項的規模，在拆分需求的時候就相當於度量了待辦事項的規模。
雞蛋估算法特別適合與最小可上市功能（MMF）一起使用。有些場合下，比如最小可行產品1.0已經上線了，要根據運營情況進行配套的增強升級，直接可以把MMF看成是雞蛋，統計MMF個數作爲規模。
國內例子和評論
- 廖靖斌：打牌好像不太流行了，流行不估算，把需求拆分到差不多大，迭代儘可能短，看看每個迭代能做幾個。
- 王洪亮：真的流行不估算，不估算直接省掉估算的時間浪費，還要保持可預測性。
- 鄭知道了（鄭斌）：我們打了很多個迭代的牌，最後發現打來打去 最後算出來故事點決定的需求數是相對穩定的。既然如此，還要打牌幹啥？直接數個數就好了。打牌確實能起到一個需求澄清的作用，但是多數情況下需求本身的歧義不大。
- 陳勇：恆生電子某個項目用的就是這個，第一個迭代做8個頁面結果沒做完，第二個起改成7個，一直做了8個迭代，不快不慢。
- 徐陳飛：我這邊現在有團隊已經採用了類似雞蛋估算，也有客戶逐步在向這個方向靠，但是需求結構還是守住的，confluence的一頁紙需求方法挺適用這類情況的，並且特定如運維團隊的需求很難用迭代去計劃的時候，雞蛋也的確是不錯的方法。
- 高雲海：我現在基本數個數，的確不用估故事點，也挺準；也可以把故事都分拆成任務，然後數任務個數，做燃盡圖，也不錯。
國外情況
https://www.infoq.cn/article/book-review-noestimates?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global
https://www.stevefenton.co.uk/2018/07/estimates-noestimates-no-estimates/
https://oikosofyseries.com/no-estimates-book-order
Twitter有#NoEstimates的標籤，可以查到大量關於此主題的發言
致謝
感謝貢獻例子和觀點的夥伴-廖靖斌，王洪亮，鄭斌，陳勇，徐陳飛，高雲海。
感謝羣主徐毅組織敏捷教練小夥伴們羣，讓大家暢所欲言。感謝參與討論的其他夥伴（由於人數衆多，不一一列舉）。