故事點

故事點是敏捷專案中常見的估算故事大小名稱。結合 XpVelocity，它們提供一種技術來協助規劃，預測故事何時可以完成。

在估算工作時，常見的方法是使用工時來估算，例如程式設計師說「這將花費我兩天時間」。在敏捷的早期，許多人，特別是 ExtremeProgramming 社群中的人，發現團隊使用這種方法很難提出有用的估算，即使他們採用了 IdealTime 方法。我們發現最有效的估算方法是根據故事彼此的相對大小來估算，然後利用過去的經驗來確定在一個迭代中可以完成多少工作。 [1]

為了確定故事的點數，我們比較粗略的相對大小。如果我們要估算「調整 foobar」的故事，我們會尋找我們已經估算過類似大小的故事。我們感覺它與「翻轉協同效應位元」的大小差不多。然後我們查看「翻轉協同效應位元」的故事點數，並為「調整 foobar」給予相同的點數。

使用故事點的團隊會使用一小範圍的故事點來工作。常見的範例可能是 1、2、4、8 或 1、2、3、5、8 [2]。通常，系列中的最高數字代表「太大」，應該進一步細分。 [3]

分配故事點應該是快速的工作。只有當人們對估算有不同的看法時，才應該展開討論，在這種情況下，進行討論是有用的，因為這通常表示故事中的某些內容不清楚。使用 ThrownEstimate 是快速推進事情的好技術。

要根據時間制定計畫，請使用 XpVelocity。

有些團隊不喜歡使用故事點，而更喜歡使用 StoryCounting。我對這兩者沒有偏好 - 兩者似乎都能發揮同樣的作用，因此由團隊嘗試並選擇最適合他們的。