检查和产品待办事项列表——回到Scrum框架的基础(17)
Scrum建立在经验过程控制的基础上，检查是三大支柱之一。
在一个或多个Scrum事件中检查每个Scrum工件，以检测不期望的差异。如果您感觉有些事情没有像预期的那样运行，那么请与您的团队一起仔细查看您的工件，看看可能会发生什么。
检查是指在实现既定目标的过程中发现不希望出现的差异。
让我们以产品待办事项列表为例。
产品待办事项列表至少要在Sprint计划和Sprint评审期间进行检查，以检测与产品目标相比，产品可能会成为什么样子，以及有一天它可能作为功能提供什么(包括短期和长期)。
通常整个Scrum团队和涉众都会参与其中。
产品待办事项列表列出了预计有一天会成为产品一部分的项目。如果你仔细看了这些，它们真的能实现产品目标，甚至是团队和组织的使命愿景吗?重叠的部分是什么?差距是什么?
当然是产品负责人，其他团队成员也会受益于让终端用户参与到这些对话中。他们在找什么?他们的挣扎是什么?我们想要解决这些问题吗?这些是否与产品目标一致?如果有，我们能在产品待办列表中找到这些吗?
在产品待办事项列表中，哪些项目似乎没有解决最终用户表达的任何挑战，也没有解决产品目标?用户是否忽略了这些?或者这些条目没有意义吗?或者这些真的是用户从未想过的创新?
简介:
“你是否检查产品待办事项列表，以发现产品预期未来的差异?”
提示:与整个团队一起评估产品待办事项列表。为了应对用户的挑战，可能还缺少什么?产品待办事项列表中哪些内容可能过多，而在产品中是不需要的?
我们希望您能在这些短信中找到价值，如果您正在寻找更多的澄清，请随时与我们联系。
PS:下周我们将讨论Sprint Backlog和Inspection。
如果您想更深入地了解我们在本博客系列中所涉及的核心概念，那么当然可以看看我们的专业Scrum大师研讨会。
不想错过任何一个吗?有专业的Scrum基础系列吗每周收到你的邮箱。
