Sprint评审也被称为“sprint demo”，是一项迭代增量的协作技术，用于确保所有干系人，均了解敏捷团队在每个sprint结束时需要交付的价值。故而，对sprint 评审来说，核心干系人的参与是至关重要的。

在这一过程中，需要评审已经完成的，以及计划了但却没有完成的工作。完成的工作要演示给干系人，因此这个过程也就被成为sprint演示（sprint demo）。Sprint的评审演示发生在每个sprint的结束时期，sprint回顾之前。sprint demo评审需要扩展的干系人团队参与，沟通、验证与识别团队是否达成了既定的目标。

想要提高sprint demo，可以应用CMMI模型中项目监控、集成项目管理、验证与确认过程域中的实践。

集成项目管理

每个sprint结束时，其目标都是交付一个潜在可用的产品。为了交付sprint中user story所执行的工作，应依据DoD的准则来进行度量。让项目的干系人参与到过程中来，以便确定他们的期望得到满足，使他们的问题在当场得到解决。问题的解决可以是一个解释，或者是对产品backlog的调整。这一过程也应邀请客户参与，因为客户是项目的主要干系人。

策划sprint的评审会议，使得所需的干系人参与进来是一项挑战。如果没能做好，便可能会给团队和产品带来负面的影响。借助集成项目管理过程域中的实践，我们来看看如何改进sprint评审过程：

-  将sprint评审与顶层计划中的里程碑集成在一起。里程碑应该被清楚的定义，并向下延伸至sprint团队以外的干系人的工作计划中。

-  确保计划的更新，确保干系人能及时得到通知。Sprint评审是核心的里程碑，不应让干系人对此存有疑惑。

-  发布sprint评审的日期、时间、目标，以便干系人做好准备，高效参与。在第一次会议之前，或者有新干系人加入时，需要让与会人员了解敏捷团队是如何工作的，这将提高sprint评审会议的效能。

-  关系到关键干系人参会的任何问题都应被立即识别与解决，以便将干扰降到最低；任何与完成工作相关的问题，都应由团队在会议上解决。那些解决不了的问题，可能会成为新的backlog，或更新在既有的backlog中。团队应该从sprint评审中汲取经验，并将其在sprint回顾中分享。

一个高效的sprint评审会议，是与关键干系人建立信任的最佳途径之一。集成项目管理过程域中的信息组件，将为管理关键干系人提供优秀的资源。

项目监控

CMMI模型中的项目监控过程域，通过确保团队按计划开展工作，从而提升sprint评审的结果。例如：

-  要求并确保团队成员出席每日站会

-  要求每日站会讨论与决定三类问题：“已完成了哪些工作”、“将要开展哪些工作”以及“是否有障碍影响当前的计划”

-  确保相关干系人受邀且参加了既定的sprint评审里程碑

-  要求站会与sprint评审中发现的问题，在会议上就得到解决或变更了产品backlog

确认

在确认的环境中，敏捷项目执行sprint评审时，又意味着什么呢？如果demo是由开发团队主导的，还算是确认吗？CMMI模型中，确认过程域明确提出了对确认过程的要求，以提高团队信誉。

-  确保选择确认的事项关系到最终用户的需要。比如最终用户可能需要用户手册、安装说明、培训材料或者工作软件，这些也应作为确认的事项考虑进来。

-  确保确认被正确地执行，相关数据与结果被记录，且目标透明。

-  让最终用户或最终用户的倡议者参与sprint评审过程。有些公司还会直接邀请用户参与，并与他们发表对产品的意见。

-  将确认的状态汇报给高层管理者。在sprint评审会议时，有高层管理者的出席会有效增加敏捷团队的信心。