Scrum的需求是以User Story的方式來描述，每個Story的規模大小則用Story Point來做為估計值。
Scrum的需求是以User Story的方式來描述，標準的範本就像是As a [user role], I need [some business value] so I want [some feature]。而所有的User Story都會記錄在Product Backlogs之中，並照PO認定各個Story的價值優先順序排列。除此之外，Product Backlogs還會記錄每個Story的規模大小估計值-Story Point。
Story Point的值是表示相對大小，而不是絕對大小，所以它並沒有單位，意思是如果Story A所估計的值為4的時候，並不表示它將會是4小時或4天完成，僅代表它的估計規模會是規模為2的Story的兩倍。如此設計的用意在於每個團隊的開發速度是有差別的，但對問題的相對大小則應該都會是類似的。
估算每一個User Story的Story Point值是團隊全體的工作，也只有他們能夠參與估算。因為他們才是實際上知道怎麼完成這些工作的人。在傳統的專案中，工作的大小通常會是由專案經理或是系統分析師這類所謂經驗較為豐富的人來估計，但由於他們不是最後負責開發的人，並通常只以自身一個人的能力為基準來做預測，因此相較於實作團隊所做的預估，多數會過於樂觀，再加上大頭們都會相信這種擲筊做出來的猜測跟大樂透名牌一樣準，要求這類的預言一定得實現，因此就會造成日後專案進度完全無法依照計畫進行，然後還是被要求得達成原訂進度的慘劇不斷發生。
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才能完成，便可以此來預估規劃專案Release的時程。
