在敏捷軟體開發方法中，尤其在討論產品待辦事項開發優先順序時，總會有個詞不斷提及，那就是「價值」（Value）。那到底價值是什麼呢？

在比較顯性的層次裡，通常會把價值等價於商業價值，也就是實際對使用者產生正面影響的程度。當談論價值高低，除了、該項目對客群的正面影響程度，通常也會將目標客群的群體數量、客群對營收的影響、該待辦事項對來在於該客群營收的影響等因素納入考慮。

如果某個待辦事項對 A 客群有很好的正面影響，但是 A 客群只佔總使用者的 20%，那或許就會寧願把資源先專注在另外可能對佔 60 ~ 80% 數量的客群的待辦事項為主。但若是 A 客群佔了整體營收的 80 ~ 90%，那就算人數再少，也會優先考慮該待辦事項。

然而如果只認定顯性商業價值才是價值，再安排優先序時，就會容易發生衝突。因為通常會將價值的範圍限縮在將功能性的待辦事項，導致非功能性的待辦事項被忽略、延後。

比如說某類技術性待辦事項、例如穩定性與效能相關、提高可維護性、加強監控與反應速度的警告通知等等。這類待辦事項通常難以定義其商業價值，或是知道其重要程度的工程師不一定有能力轉換成商業語言讓產品負責人理解，這都導致立場難以相互理解。

更深層的價值，則來自於敏捷軟體開發的本質之一，也就是透過這樣的待辦事項，是否能夠得到回饋？可能是一張研究型的待辦事項，但它將原本許多的未知資訊變成已知，這是一種回饋，那就有價值。比如說，這次 Sprint 儘管沒有符合預期，但透過 Sprint Retrospective，了解到團隊合作上的盲點與缺陷，這也是一種回饋，那也就有價值。

儘管這些深層的價值，不一定會在排序時納入考量。但對於該次 Sprint 的意義則相當重要，只要取得回饋，該 Sprint 就有對應的價值。而這些價值，則可能會對未來顯性的商業價值的交付，有著墊腳石般的影響。