故事點該是…？
在目前，我偏好 Teddy 在「如何估算story point？」一文所分享的估算方式，讓 Story points 本身不包含時間因素，單純反應相對大小，這個現今社會強力關注的「時間」，則由拆解後的任務所估計的理想工時來表述。這很可能是務實的作法，當任務已經有負責人(們)，所估計出來的理想工時較為現實，成員可以考量自己的過去經驗、技能與可能的風險。
《Scrum 精隨》一書給出一段說明，部份摘要如下 (維持簡中版用詞)：
故事點用於衡量 PBI 的大小和數量。故事點受很多因素的影響，如複雜度和實際大小。
故事不一定是看起來大就大。故事本身可能表示開發一個複雜的商業算法。最後結果不太大，但要開發它，工作量可能會很大。
故事可能表面上很大，但其實並不複雜。例如，我們要在一個有 60,000 個單元格的工作表上更新每個單元格。
再來看 Mike Cohn 的文章 What Are Story Points?
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work
具體該會包含什麼呢？
The amount of work to do (工作量)
The complexity of the work (工作複雜度)
Any risk or uncertainty in doing the work (風險與不確定性)
effort 該不該列入 story points 的考量當中，在 Mike 文章下的回應也可以看到相關的討論，有興趣的讀者可以再行查閱。
順藤摸瓜，我們還可以找到更多相關的文章，也發現各處對於 Story points 的認定與涵蓋範圍是有所區別的，例如：
小結
究竟 Story points 應當是什麼？應當包含什麼？我們在上面的相關資源看到了複雜度(complexity)、難度(difficulty)、大小(size)、工作量(effort)、時間(time)、風險(risk)與不確定性(uncertainty)等。這會是團隊真正運用 Story points 前的先修課，也是形成共識前的一哩路。若沒有特別的堅持，不妨邀請團隊一同討論，當大家確切理解點數背後的意涵，將讓隨後的共識更為具體。
同時，我們也要記得，Scrum 估算活動的本意是希望透過這樣的安排，促進團隊釐清故事，透過討論找出被遺漏的重點，並對照過去經驗進行修正(如故事拆解)，最終形成共識。
