← 隨筆

Sprint Review 與 AI：為什麼演示不能取代關於價值的對話

實務解析 AI 如何改變 Sprint Review：它在哪裡降低了準備成本、為什麼不能取代與利害關係人的工作會議，以及如何避免把衝刺檢視變成經過打磨的 AI 演示。

14 分鐘閱讀
Telegram原文
Sprint Review 與 AI：為什麼演示不能取代關於價值的對話

這是探討 AI 如何改變跨職能開發團隊經典會議系列文章的第四篇。在第一篇文章中，我分析了 Backlog Refinement ，並說明 AI 能加速素材準備，但不能取代團隊對意義的檢驗。第二篇談的是 Sprint Planning:AI 彙整計畫草稿，但不承擔團隊承諾。第三篇談的是 Daily Scrum:AI 準備衝刺進度的訊號，但不代替團隊進行同步。現在順理成章地轉向 Sprint Review，剖析最誘人的錯誤：把關於價值的生動對話變成漂亮的 AI 演示。

Sprint Review 看起來是 AI 的理想舞台。衝刺結束時，一切都已齊備，很容易拼湊出吸睛的簡報：Jira 中已關閉的任務、已合併的 pull request、程式碼變更、新畫面、更新後的指標、支援工單、使用者回饋。AI 可以在幾分鐘內彙整 release notes、草擬演示腳本、製作投影片、統計完成了多少工作，甚至生成一份關於使用者意見的整齊摘要。

乍看之下這是純粹的收益。更少的人工準備。更少「開會前五分鐘再決定要展示什麼」。更少無聊地逐項列舉已完成的事。簡報看起來很專業，release notes 寫得連貫，指標視覺化得很漂亮。

但這裡有個陷阱，而且比 Daily Scrum 中的更嚴重。

Sprint Review 的存在不是為了展示。它的任務是與利害關係人一起檢視衝刺的成果、討論朝 Product Goal 的進展，並調整 Product Backlog。如果 AI 把 Sprint Review 變成經過打磨的演示，團隊得到的是更漂亮的簡報，卻失去了最重要的東西：誠實的回饋、共同決定「接下來做什麼」，以及對產品的責任。

「AI 可以去除準備的例行工作，但 Sprint Review 的價值不在演示，而在決定產品要改變什麼。」

為什麼需要 Sprint Review

在 Scrum Guide 2020 中，Sprint Review 的描述相當嚴格。它是衝刺倒數第二個事件，對為期一個月的衝刺，timebox 最多四小時。其目的是檢視衝刺的成果並決定後續的調整。Scrum Team 向關鍵利害關係人呈現工作成果，並討論朝 Product Goal 的進展。Scrum Guide 還特別、幾乎帶著論辯意味地補充：「The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation」——這是工作會議，團隊不應把它縮減為簡報。

這是整篇文章的關鍵句。Sprint Review 不是產品負責人對工作的驗收、不是向管理層的報告、不是給客戶的行銷演示，也不是「我們很棒」的儀式。它是團隊與利害關係人一起審視完成了什麼、周遭改變了什麼，並決定接下來做什麼的時刻。事件的成果不是掌聲，而是調整後的 Product Backlog。

作為額外的參考， Scrum Guide Expanded v2026.1也有用，但僅作為 companion 來源，而非 Scrum Guide 的新正典版本。對本文而言，它的重要性在於實務框架：Sprint Review 關乎價值真正流向利害關係人，以及共同調整產品計畫，而非狀態簡報。在關於 AI 的章節中，它將模型描述為 supervised decision-making partner：AI 可以強化透明度、檢視與調整，但不能取代人的責任，也不能取消對過程的經驗性控制。

因此，我會透過五項功能來描述 Sprint Review 的目的：

  • 檢視衝刺的真實成果，而非關於成果的敘述；
  • 收集來自利害關係人與使用者的誠實回饋；
  • 檢查朝 Product Goal 的進展；
  • 共同決定接下來做什麼；
  • 調整 Product Backlog，而不只是展示已完成的事。

這是討論 AI 的框架。如果工具幫助團隊更好地執行這些功能，它就有用。如果它只是讓演示更漂亮，它可能很方便，但不一定改善產品。

通常哪裡出了問題

Sprint Review 的問題很少在於團隊不會展示已完成的事。問題在於這個事件隨著時間退化為單向演示：團隊準備簡報、展示畫面、列舉已關閉的任務，利害關係人禮貌地點頭，有人說「很好，謝謝」，然後大家各自散去。Backlog 卻沒有改變。Scrum.org 在 Myth 12: The Sprint Review is a Demo一文中直接剖析了這個反模式：演示可以是事件的一部分，但 Sprint Review 的目的是最大化回饋並降低風險，而不是做一場簡報。

那麼這場會議就開始背離其目標。團隊討論的是如何更漂亮地展示，而不是什麼值得討論。利害關係人來不及提供回饋，因為團隊「天真地沉迷於自己的簡報」——Scrum.org 在材料中特別指出這一點 How to Engage Stakeholders in your Sprint Reviews。尖銳的問題沒有被提出。所建構的東西與市場所需之間的落差，很晚才浮現。Product Backlog 維持著會議前的樣子，儘管這場活動的全部意義正是根據新資料來改變它。

在 AI 輔助的脈絡下，這個問題可能加劇。如果模型每個衝刺都生成簡報、release notes 和成就清單，團隊很快就會習慣「回顧已經準備好了」的想法。於是 Sprint Review 變得更加平滑：打開 AI 投影片、讀完 release notes、展示指標、收到禮貌的「謝謝」，然後結束會議。

看起來很專業。但問題不在於簡報彙整得多麼連貫。問題在於：如果現實改變了，團隊是否改變了他們的 Product Backlog。

AI 真正有幫助的地方

AI 在 Sprint Review 中有一個相當實際的助益領域。它可以去除準備工作的例行瑣事，並把團隊在衝刺尾聲容易遺失的東西浮上檯面。當來源很多時，這特別有價值：issue tracker、pull requests、CI/CD、產品分析、支援工單、商店評價、問卷結果、使用者訪談紀錄。

但在這裡重要的是不要過度承諾。即使是最新的 DORA State of AI-assisted Software Development 2025 也把 AI 描述為既有組織實務的放大器，而非更好的交付本身的獨立保證。對 Sprint Review 而言，這意味著一件簡單的事：如果團隊已經懂得誠實地談論價值並調整 backlog，AI 會讓進入這場對話的內容更豐富。如果 Sprint Review 早已變成演示儀式，AI 只會讓這個儀式更快、更漂亮。

好的 AI 助手在 Sprint Review 之前收集的不是「如何更有效地展示」，而是對產品決策有用的脈絡：

  • 衝刺期間產品實際上有什麼改變，以及這與 Product Goal 有什麼關聯；
  • 增量中哪些部分已準備好接受檢視，哪些最好誠實地作為未完成項展示；
  • 先前的發布之後，產品指標說了些什麼；
  • 來自使用者與支援團隊的回饋是什麼，包括矛盾且令人不適的部分；
  • 過去幾個衝刺的哪些假設獲得證實，哪些沒有；
  • 哪些未解的產品問題值得提出來與利害關係人討論；
  • Product Backlog 中哪些項目可能已經失去時效，或者相反地優先級上升了。

在這種模式下，AI 並不取代 Sprint Review。它降低了準備這場會議的成本。團隊帶來的不是原始資料，也不是匆忙拼湊的投影片，而是一幅已經結構化的圖像：這是結果，這是資料，這是回饋，這是未解的問題。這讓團隊能花更少時間收集事實，花更多時間討論「我們現在要在產品中改變什麼？」。

這延續了本系列先前文章的邏輯。在 refinement 中，AI 協助彙整待討論的材料。在 planning 中，提供計畫的選項。在 Daily Scrum 中，提供衝刺進展的訊號。在 Sprint Review 中，它可以彙整結果與回饋。但在這四種情況下，人的部分都不會消失：團隊與利害關係人必須確認什麼重要、什麼改變了，以及該做出什麼決定。

兩位 Sprint Review 參與者討論回饋，以及要在 Product Backlog 中改變什麼的決定
AI 作為準備層很有用：它彙整結果與回饋，而團隊與利害關係人決定要在 Product Backlog 中改變什麼。

為什麼 AI 不該把 Sprint Review 變成演示劇場

AI 輔助 Sprint Review 最危險的版本看起來非常有說服力：模型生成帶有漂亮投影片的簡報、連貫的 release notes、「衝刺關鍵成就」清單、指標圖表，以及一份平滑的使用者回饋摘要。有時還會加上對 Product Goal 的自動預測，以及對 backlog 的建議變更。

從形式透明度的角度來看，這很方便。從 Scrum 的角度來看，這可能是一種退化。

首先，這種形式會強化單向性。AI 演示越漂亮，「把」會議「辦成」簡報的誘惑就越強。注意力從回饋轉移到展示上：團隊在為投影片辯護，而不是邀請利害關係人一同爭論價值。

其次，AI 對回饋的摘要可能正好抹去 Sprint Review 存在的目的。回饋的真正價值在於矛盾、微弱訊號、令人不適的反對意見，以及罕見但重要的評論。平滑的平均化摘要很容易丟棄離群值，而在產品中，離群值往往正是訊號。這是資訊完整性與錯誤資訊的典型風險，描述於 NIST 的生成式 AI 概況.

第三，模型可能自信地编造出数据中并不存在的洞察。虚构在 Sprint Review 中尤其危险，因为生成的关于用户的「结论」很容易变成产品决策。如果 AI 写「用户要求 X」，而实际上那只是两个工单和一次访谈，团队就有基于幻觉修改 Product Backlog 的风险。

第四，团队可能开始把产品判断委托给工具。如果 AI 提出了 backlog 变更，看起来似乎可以直接接受。如果 AI 说 Product Goal 已达成，看起来似乎没什么可讨论的。这不是 Sprint Review 的自动化，而是把责任转移到不可能有责任的地方：对产品负责的是产品负责人和团队，而不是模型。

「AI 演示可以是有用的输入。它不应成为关于价值对话的替代品。」

继续案例：B2B LMS 和 email 提醒

我们沿用前几篇文章中的同一个案例：B2B LMS 平台、必修课程、向未在截止日期前完成必修课程的员工发送 email 提醒。在 planning 中，团队选择了一个狭窄的 Sprint Goal：系统向有未完成必修课程且临近截止日期的活跃员工发送一条正确的提醒，并保存可验证的发送历史。

在没有 AI 的情况下，这样的冲刺中的 Sprint Review 很容易沦为演示。团队展示提醒设置界面，演示测试邮件，说「调度器在工作，去重已到位，历史日志在写入」，利益相关者点头，有人称赞邮件设计。形式上一切都好。Backlog 没有变化。

但团队可能错过最重要的东西：提醒发出去了，但打开率低，因为邮件主题不好；支持部门已经收到几起「为什么我会收到一门我并非必须参加的课程的提醒」的请求——也就是说 eligibility 边界的工作方式与预期不符；一个大客户要求个性化时间表，这可能会改变下一个冲刺的优先级；而对状态 expired的解读，团队认为在工作范围之外，实际上对利益相关者很重要。

AI 在这里可以帮忙。在 Sprint Review 之前，它收集输入：发送了什么、发给了谁，打开率和点击率如何，支持部门收到了哪些请求及其内容，试点客户留下了哪些反馈，哪些 backlog 条目与这个 Sprint Goal 相关。这是很好的讨论材料。

但价值只在会议上出现，当团队和利益相关者采取下一步时：决定低打开率是产品问题，而不是表面修饰；eligibility 边界需要澄清并作为单独条目放入 backlog；大客户的个性化时间表是战略决策，而不是快速修复；以及解读 expired 是时候从「工作范围之外」移到最近的优先级了。AI 给出了结果和数据。团队与利益相关者调整了 Product Backlog。

反模式

以下是我在将 AI 引入 Sprint Review 时会单独跟踪的几个反模式。

1. AI 让演示更漂亮，而会议仍然是单向的

如果精力都花在打磨幻灯片和 release notes 上，Sprint Review 作为演示会得到加强，而不是作为 working session。更有用的是让 AI 准备给利益相关者的问题和开放的产品议题，而不只是对已完成工作的炫目展示。

2. AI 反馈摘要平均化并丢失微弱信号

流畅的摘要读起来方便，但危险在于它会丢弃矛盾和罕见但重要的评论。反馈应当带着分歧和异常值一起呈现，而不只是平均化的「整体情绪」。

3. AI 编造数据中不存在的产品洞察

「用户想要 X」听起来很有说服力，但需要核实：结论基于多少个信号，这是不是幻觉，它是否用大众需求替换了罕见情况。来自模型的洞察是假设，而不是决策。

4. 指标被展示为成就，而不是决策的契机

「发送了 10 000 封邮件」是活动，而不是价值。Sprint Review 应把指标与 Product Goal 联系起来，并询问它们改变了计划中的什么，而不是把它们当作冲刺进展良好的证据。

5. AI 提出 Product Backlog 变更，未经讨论就被接受

模型的建议可以是有用的输入，但调整 backlog 是产品负责人与团队和利益相关者共同做出的产品决策，而不是自动应用 AI 建议。

6. 面向管理层的演示剧场，而不是为调整而做的检视

如果 Sprint Review 变成「向老板展示我们很棒」的表演，AI 只会让表演更有说服力。这会破坏对事件的信任，并让团队失去诚实的反馈。

角色将如何变化

AI 不会取消 Scrum Team 内的角色，但会改变 Sprint Review 准备和进行中的重点。手动组装演示文稿的价值降低。对结果进行诚实检视、处理反馈和共同做出产品决策的价值更高。

角色糟糕 AI 场景下的风险成熟的 AI 使用
产品负责人接受 AI 生成的反馈摘要和所提议的待办事项变更作为现成决策，并停止自行思考价值。将 AI 输入作为材料使用，但自己主导关于价值的对话，验证洞察，并对产品待办列表的调整负责。
开发者将准备时间花在打磨 AI 演示上，而不是诚实展示哪些已完成、哪些没有。使用 AI 快速汇总结果和风险，并与利益相关者一起诚实检视增量。
Scrum Master将引导交给幻灯片，只关注演示的时间安排。保护 Sprint Review 不沦为演示，帮助吸引利益相关者参与，并将焦点保持在调整上。
利益相关者得到一场流畅的 AI 演示，礼貌地点头，却不给出真正的反馈。看到真实的结果和数据，提出尖锐的问题，并影响产品优先级。
质量工程师 / QA 工程师确认 AI 生成的“已完成”清单，并制造增量已就绪的假象。帮助如实展示哪些符合完成定义、哪些不符合，以及质量风险留在哪里。
UX/UI 设计师被排除在视野之外，因为 AI 演示聚焦于功能和指标。带来用户观察和体验反馈，帮助将结果与真实价值联系起来。

AI 辅助 Sprint Review 的实用过滤器

我不会从引入“AI 演示生成器”开始。我会从一个更窄的问题开始：什么样的输入能帮助团队和利益相关者更快地做出诚实的产品决策？之后，AI 可以作为准备层使用，而不是事件的替代品。

如果 AI 输入有助于回答以下问题，那么它对 Sprint Review 就是有用的：

  • 产品中真正改变了什么，这与产品目标有何关联？
  • 哪些已准备好接受诚实检视，哪些需要作为未完成项展示？
  • 数据和反馈说明了什么，包括相互矛盾的反馈？
  • 哪些假设得到证实，哪些失败了？
  • 哪些开放的产品问题值得与利益相关者讨论？
  • 产品待办列表中的哪些条目需要修改、添加或移除？
  • 我们根据结果将做出什么决策，而不仅仅是我们将展示什么？

反过来：如果 AI 输入主要回答的是“如何更漂亮地展示已完成的工作”，那就不是 Sprint Review。那是演示。演示对沟通可能有用，但不应将其与对结果的检视和产品待办列表的调整混为一谈。

数据治理与卫生

Sprint Review 对数据尤其敏感，因为 AI 准备很容易开始从支持工单、CRM、访谈记录、问卷、应用商店评价和客户往来通信中收集反馈。访问范围越广，摘要就越有说服力。但敏感信息泄露、语义失真以及过度依赖模型自信但不完整的输出的风险也越高。这些风险类别在以下文献中有很好的描述： NIST 生成式 AI 概况、 NIST AI 风险管理框架 1.0 以及 OWASP Top 10 for LLM Applications 2025.

团队应事先约定：哪些反馈来源允许用于 AI、用户数据如何匿名化、谁可以看到生成的摘要，以及是否可以向外部的利益相关者展示客户的原始引述。在处理用户和客户的个人数据时，以下参考是有用的： EDPB Opinion 28/2024 和 ICO monitoring at work impact assessment ——不是作为文章的法律指引，而是作为对法律依据、数据最小化、透明性和相称性的提醒。

在实践中，这意味着：不要把多余的个人数据拉进模型，将事实与生成的解读分开，将 AI 洞察标记为假设，依据原始来源核实用户引述，并且不要在 Sprint Review 上展示无法用数据证实的“结论”。AI 应该帮助团队诚实地看到结果和反馈，而不是制造一幅有说服力但未经核实的图景。

实践结论

AI 确实可以让 Sprint Review 更有用。它可以消除准备中的例行工作，提前汇总冲刺结果，将其与指标关联，聚合反馈，突出计划与现实之间的差异，并提出与利益相关者讨论的主题。

但这只有在团队理解边界时才有效：AI 准备输入，而不是主持 Sprint Review。它帮助看到结果和数据，但不决定它们对产品意味着什么。它可以收集反馈，但本身并不创造关于价值的诚实对话。它可以提出待办事项变更，但不承担对产品的责任。

因此，我会这样表述核心论点：AI 应该降低准备的成本，以便团队和利益相关者能把更多注意力留给关于价值和计划调整的对话。如果情况相反，Sprint Review 变成了一场打磨过的 AI 演示，团队就恰恰失去了该事件存在的意义：对结果的诚实检视、真实的反馈、共同决策以及对产品的责任。

成熟的團隊不會問：「我們能不能讓 AI 來彙整 Sprint 回顧？」他們會換個問法：「AI 能替我們移除準備工作中哪一部分的例行公事，好讓我們的 Sprint Review 成為一場更誠實的對話——談價值，也談產品該改變什麼？」這種說法比較不吸睛，卻更貼近真實的產品實務。

來源與參考依據

← 所有隨筆