Story Point的值是表示相對大小，而不是絕對大小，並且它沒有單位
Scrum的需求是以User Story的方式來描述，標準的範本就像是As a (role of user), I want (some feature) so that (some business value)。而所有的User Story都會記錄在Product Backlogs之中，並照各個Story的價值優先順序排列。除此之外，Product Backlogs還會記錄每個Story的規模大小估計值-Story Point。

Story Point的值是表示相對大小，而不是絕對大小，並且它沒有單位，意思是如果Story A所估計的值為4的時候，並不表示它將會是4小時或4天完成。如此設計的用意在於每個團隊的開發速度是有差別的，但對問題的相對大小則應該都會是類似的。

為每一個User Story估算Story Point是團隊的工作，也只有他們能夠參與估算。因為他們才是實際上知道怎麼完成這些工作的人。在傳統的專案中，工作的大小通常會是由專案經理或是系統分析師這類所謂經驗較為豐富的人來估計，但由於他們不是最後負責開發的人，只能以自身一個人的能力為基準來做預測，因此相較於實作團隊所做的預估，通常會過於樂觀，再加上大頭們都會相信這種擲筊做出來的猜測跟大樂透名牌一樣準，要求這類的預言一定得實現，因此就會造成日後專案進度一直delay，然後還是被要求得達成原訂進度的慘劇不斷發生。

Story Point的估算時間點通常會是Sprint Planning Meet的第一階段或是專門的Product Backlog Refinement meeting。先由PO說明要估計的Story細節後，再由團隊來做估計。

估計方式較常見的是用Planning Poker。首先團隊成員每個人手上會有一副撲克牌，點數通常會是以0，0.5，1，2，3，5，8，13，20，40，100等來組成，這數字的特性是越大的兩個數字相差越大，表示越大的項目越估不準，超過40就表示該項目大到無法估計，需要再細切拆成多個小Story。另一個限制是一次只能用一張牌，沒有0.5+1=1.5這種表示的方示。

團隊每個成員自行估計這個Story應為多少點，並以覆蓋牌面的方式出牌，好避免影響到其他人的估算。等大家皆出了牌後再一起開牌。若大家所估計的差距太大則表示每個人對這個Story的認知有差，因此每個人互相說明估計的理由為何，或請PO再多加解釋關於這個Story所應完成的要求後，大家便再次出牌直到取得共識。

有了全部Story的Point後，接下來就能利用由過往經驗得知每個Sprint能完成多少Story Point的值，來推算這個專案的Product Backlogs需要多少個Sprint才能完成了。