在敏捷軟體開發中，會不斷地發布可用的軟體，以盡快取得最真實的回饋，根據回饋做出對應的調整，進而避免浪費。

以 Scrum 為例，在每個 Sprint 中，都會有個事件稱為 Sprint Review，在這個事件中，我們應該將我們當次 Sprint 產出的可用軟體，讓使用者試玩，取得回饋。

讓使用者試玩典型的方式就是設立園遊會（或稱博覽會），也就是依照團隊或是變動，去設立攤位，讓參與者自由流動的去逛攤、試玩，並在試玩後給予回饋。這些回饋不限於那些變動，亦可包括產品任何的體驗。

當這個事件在初導入 Scrum 的團隊也容易產生誤解，變成是在這個事件才開始驗收，這是完全悖離當初目的的。既然這個事件是要拿取真實的回饋，所拿出來的應當是已經符合 DoD（完成的定義）的可用軟體，而不該這時候才在驗收。

應該把在 Sprint Review 操作成果的參與者當作終端使用者（當然，若能邀請實際的終端參與者最好，當實務上不一定能做到），這樣就知道什麼樣的產出是可以拿出來的，怎樣是不行的。

也不該讓 Sprint Review 成為卡住發布的事件，當產品待辦事項都已經完成時，在沒有商業層面顧慮的情況下，就應早點發布讓其發揮價值，發布應該是在 Sprint 中間不斷發生的。

而在 Sprint Review 前就發布的變動，亦可以透過商業層面的數據、抑或是 Google Analytics 蒐集到的使用者行為作為一種回饋，檢視是否符合預期，進而做出調整。

無論是試玩提供的意見、或是產品數據得到的洞見，都是產品得到的回饋，有了這些回饋，就應當去好好檢視他，去思考有什麼事我們當前能夠調整的，並將調整的成果建立新的產品待辦事項，放回產品待辦清單中，如果是重要的回饋甚至排序會安插在原本既有的排序之上呢。