今天來看敏捷專案管理中很重要（但混合式專案管理常被忽略或變種）的衝刺審查（Sprint Review）。

衝刺審查通常在每個 Sprint 結束時舉辦。主要目的是讓開發團隊展示這個Sprint 完成的工作成果，並收集來自 PO 和其他利害關係人的回饋，確保產品方向與需求一致。

衝刺審查的主要活動

展示進度或成果

開發團隊會展示在衝刺期間完成的產品增量，讓大家得知這個 Sprint 的產出。

獲得回饋

利害關係人和產品負責人會對展示的成果提供回饋，這些回饋可以讓 PO 決定是否需要調整產品待辦清單（Product Backlog），優先考慮未來衝刺中需要完成的工作項目。

評估進度與後續

團隊可以回顧專案的進展，評估是否達到了衝刺目標，好讓團隊和 PO 共同討論接下來的步驟以及是否需要對專案計劃做出調整。

衝刺審查目的

公開透明

通過展示和回饋，團隊成員和利害關係人可以了解產品的開發進度，避免資訊不對稱。

快速反應

根據回饋和專案進度，團隊可以及時對開發方向計劃進行調整，確保產出符合客戶或市場商業需求。

結語

以上是理論層面的介紹，實際操作中，我認為 Sprint Review 的重要性與執行難度都要高於 Standup Meeting（站立會議）在混合式專案管理中，衝刺審查經常被修改或簡化，這往往會降低透明度，難以獲得利害關係人的直接回饋。

舉例來說，衝刺審查會議可能會演變成技術主管、PM 與需求方之間的內部討論，這時技術主管與 PM 變成了開發團隊的代表。雖然這種設置至少讓技術主管和 PM 能夠充當開發團隊的隔離層，減少一些對商業或產品理解不深的 PO 或需求單位的干擾，但也可能導致資訊傳遞不充分，進而影響專案的敏捷性。